This page is still in draft state. Please note that the content may be subject to change.
In this module, the students will research specific topics from the field of software coding that are relevant for professional software development. The topics focus in “Coding Excellence”. These topics represent design choices for development teams when using current programming paradigms. The students will research these topics both by literature research, and by a proof of concept.
#rollenzuweisung
and click on
cex
.
Then you automatically get access to the channel(s) relevant for this module.
This module tries to encourage the analysis and discussion of what is "good code".
As a experienced programmer I can assess new trends in the software industry, and act as a multiplier within my own organization with regard to such topics,
by me ...
so that I so that I have a fact-based way of making up my mind in the VUCA world of professional software development.
The idea of this module is to use a mixed approach to clarify open issues in the domain of modern coding patterns, paradigms, and technology. This is:
Due to the rapid innovation pace in the field of software development, relying only on academic knowhow is not enough. Many relevant aspects in modern coding just haven’t been researched (enough) yet. Or, they never really will be, at least not before yet another new paradigm enters the stage, and renders them moot. Studying these aspects only by hands-on work is similarly unsuitable. Therefore, the module is split into two phases representing this mixed approach.
In phase 1, you mainly do your research and design your coding experiment. We will meet in three status workshops to discuss progress and obstacles. In addition, you will organize meetings within your subteam and with your “topic sponsor” to clarify issues. The expected outcome of this phase is the following:
Deadline for paper submission is 31.05. 07.06. (eod), so you can still take feedback from the presentations into account.
I will grade the paper as submitted. The paper will be enhanced by a 2nd part describing the outcome of the coding
experiment (see below). This 2nd part will be graded seperately. However, you are free to improve also this first
(research) part until end of this module, esp. if there were major flaws in it. You can ask me to revise my grading
for the first part then.
If you want, you can specify which group member has contributed to what part of the paper with what percentage. If such a statement is missing, I assume an equal contribution of each team member.
In phase 2, you conduct your coding experiment (implement your PoC or prototype), and evaluate the results. You add the results to your research paper. The expected outcome of this phase is the following:
The module is designed with 6 ECTS, corresponding to 180h of total workload. The subsequent table is intended as a rough time budget (per person - i.e. in a team of 2 or 3, these figures double or triple). If you experience grave deviations in your actual workload, please contact me to discuss possible solutions.
Phase | Activity | Time Budget (h) |
---|---|---|
Research Phase | Kickoff Workshop | 4 |
Principles of Scientific Working | 6 | |
Jour Fixe with supervisors (recommended every two weeks) | 2 | |
Coordination meetings within team | 3 | |
Research & paper writing | 50 | |
Designing the coding experiment | 16 | |
Preparing the research presentation | 8 | |
Presentation & Planning Workshop | 6 | |
Coding Phase | Jour Fixe with supervisors (recommended every two weeks) | 2 |
Coordination meetings within team | 3 | |
Implementation of Coding Experiment | 50 | |
Documentation of coding results (writing part II of the paper) | 16 | |
Preparing the final presentation | 8 | |
Final Presentation Workshop | 6 | |
Total Effort | 180 |
The following topics are available for this module. (Note: This list is yet tentative, and may be subject to change.) Each topic is supervised by mentor(s), who will guide you through the research and coding process. The topics require 2-3 students each.
In addition, you can propose own topics - if they fit into the general theme of the module. Please discuss this with me beforehand, early enough before the module starts (see kickoff workshop date below).
No. | Topic | Topic Mentor(s) | Partner Organization | Additional Information | Motivation Video |
---|---|---|---|---|---|
1 | tbd | tbd | tbd | tbd | tbd |
In the kickoff workshop, we collected questions and suggestions for each of the topics. See the documented post-its below.
(tbd)
There is a survey on Xoyondo (tbd) where you can book your topic preferences. (I would gladly have used officially sanctioned university tools for this, but none of them allows editing your choices after you have made them. So, this is a compromise with a relatively data-privacy-friendly 3rd party tool, which I also use in other contexts.)
You need to pick your choices until registration deadline (05.04.2025). Voting for a topic is a prerequisite for participation in this module. If you don’t want to use the given tool, let me know your preferences via another channel (e.g. email) until the deadline.
The module grade consists of several partial grades for the artifacts listed above, each based on a points scale between 0 and 3.
Grading Aspect | Weight | 0 Points | 1 Points | 2 Points | 3 Points |
---|---|---|---|---|---|
Part I of Research Paper, with research and code experiment design | 6,5 | The paper doesn't contain scientific results, and no relevant / valid sources. Either is the level of effort and commitment unacceptable, or it reflects an alarming unfamiliarity with scientific work. The code experiment is missing, or inappropriate for the task at hand. Editorial and formatting aspects (citations, chapter structure, grammar, spelling) seemingly have not really been addressed at all. | The paper presents at least some valid research, amongst less relevant or valid parts. A list of sources exists, but is not extensive or adequate. The paper reflects an rather poor level of effort and commitment, or a lack of skills in scientific work. The code experiment doesn't fit very well, and/or only vaguely addresses the research question. Editorial and formatting aspects (citations, chapter structure, grammar, spelling) show major flaws. | The paper presents valid research, with an appropriate list of sources found and evaluated. It reflects an avarage level of effort and commitment. The code experiment mostly makes sense, and by & large answers the research question. Editorial and formatting aspects (citations, chapter structure, grammar, spelling) show only minor flaws. | The paper presents immaculate research, with an extensive list of sources found and evaluated. It reflects a high level of effort and commitment. The code experiment makes complete sense and fully fits to the research question. Editorial and formatting aspects (citations, chapter structure, grammar, spelling) are without flaws. |
Part II of Research Paper, describing the outcome of the software experiment | 1,5 | ||||
Code Experiment | 5 | The code experiment is unacceptable (either very little effort spent, or coding skills lacking). Documentation is missing or unusable. | The code experiment has major flaws, and/or reflects quite little effort. Documentation is sparse and/or only of limited use. | Code experiment is "ok" implemented, with some minor problems or flaws. It reflects average effort. The documentation by and large usable to understand and run the code. | Code experiment is very well implemented, up to professional standards. The effort invested it high or even exceptional. The documentation is easy to understand, and appropriate to understand and run the code. |
Research (intermediate) presentation | 1 | Presentation is not an acceptable summary of the project. Examples and demos are missing or do not make sense. Presentation is unacceptably poorly coordinated. | Presentation summarizes only some key aspects of the project. Examples and demos are inadequate, or poorly match the presentation. Presentation has many style breaks and inconsistencies, but with still recognizable "common thread". | Presentation summarizes the key aspects of the project in a somewhat understandable manner. The selected examples and demos mostly fit to the statements of the presentation. Presentation is appropriately coordinated, with individual breaks in style and inconsistencies. | Presentation summarizes all relevant aspects of the project in easily understandable fashion. The selected examples and demos illustrate the statements of the presentation. Presentation is very well coordinated and is perceived by the viewer "as one". |
Final presentation of results | 1 |
A maximum total of 45 points can be achieved. A 1,0 is awarded for 41,25 points or more, a 4,0 for at least 15 points. Grades in between are interpolated accordingly. 0 points in any category automatically leads to a 5,0, i.e. a failure of the whole module.
The above activities are assessed as a team effort. I assume that all members perform equally. If this is not the case (e.g. if one team member clearly does not participate or participates significantly less in the group work), then I reserve the right to reduce this team member’s share of the team performance. This means that the individual grade can also deviate from the team grade and, in extreme cases, lead to a failing grade for the course.
It is best to make sure that your individual contribution is recognizable, e.g. that you push commits into the system yourself for Pair or Mob Programming (when it comes to coding).
Individual Contribution | < 30% | 30 … 80% | 80 … <100% | 100% |
---|---|---|---|---|
Level of individual contribution to team efforts | The student was hardly involved in any interactions at all within the team in this activity. Contributions are not visible, can only be guessed. | The student was only occasionally / superficially involved in this activity. Contributions are scarce but visible. | The student has contributed slightly below average in this activity. | The student has played an active role in the activity, and has performed in line with the assessment of the activity. |
We discuss the goals, structure, organizational details, and grading for this module. In addition, and most importantly, you get a brief presentation of the available topics, and can put down your preferences.
Room: 0502 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.
You can start with working on this module.
We discuss how a scientific, yet practical and hands-on, paper should be written. This includes Do's and Don'ts, a brief introduction to the most important citation styles, how to structure a paper, how to select appropriate sources, how formulate a good research question, how to set up a coding experiment (and how to document it), what makes a good research presentation, and so forth. You can read about the content in this slideset.
Room: 0502 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.
You and your team mates have clarified all open issues with regard to writing a coding-oriented research paper.
Each team presents its research results and the setup for their coding phase. There may also be a guest lecture on a specific topic.
Room: 0502 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions. In addition, there is a video conference. Video conference link: https://th-koeln.zoom-x.de/j/61405401723?pwd=NguHATXUrYwqCvx35arOeFlr0veX5p.1
Presenting your team's research, and getting feedback from peers and supervisor. The agenda times are a little approximate, and leave room for discussions, questions, and breaks.
There will be a video recording of the relevant parts available afterwards, in case you are not available at that time.
We will look at software demos and how to do them well in this workshop. Any presentation you'll give lateron, be it in your professional life before a customer, at a conference, or in the Master colloquium - a good demo of actual code is often what sets a presentation apart from others. A demo needs a storyboard, it should tell a little story, and it needs to be paced well. You will develop the storyboard for your final presentation in this workshop. In addition, we'll give each other a glimpse on the progress of our coding experiments, and to discuss open issues. You can read about the content in this slideset.
Room: 0502 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.
You have a script for your final demo, and you and your team mates have clarified all open issues with regard your coding experiment.
A video recording is available here. (Password: Z+2*2AHQ).
Final presentation of the overall project and its results. Open to guests from outside the project. There may also be a guest lecture on a specific topic.
Room: 0502 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions. In addition, there is a video conference. Video conference link: https://th-koeln.zoom-x.de/j/61405401723?pwd=NguHATXUrYwqCvx35arOeFlr0veX5p.1
Presenting your team's final results from the code experiment, and getting feedback from peers and supervisor.
There will be a video recording of the relevant parts available afterwards, in case you are not available at that time.