Coding Excellence (CEX), SS24

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.

Study Program and Module Description

Master Digital Sciences (specialization Software Architecture) (see also module description in the study program web site)

Begin/End and Scheduling

05.04.2024 - 19.07.2024. Organized as half-day or full-day workshops (on Fridays), specific dates and agenda see below.

Location

Room: 0502 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions

Video conference link: https://th-koeln.zoom-x.de/j/64374849021?pwd=NzkvMTdLbGlHZzFEenZoUG5CYy84Zz09 (only in exceptional cases and if explicitly communicated in advance for the day)

ILIAS/ILU Course for the Module

https://ilu.th-koeln.de/goto.php?target=crs_296859&client_id=thkilu

Registration for the Module

Please join this ILIAS/ILU course, and vote for your topic preferences (see description). Deadline is 05.04.2024. Please remember that you must additionally register for the exam via PSSO. The registration deadlines for this can be found on the F10 information pages of the TH Köln.

Maximum / Minimum Number of Participants

The maximum number of participants is 10. If there are less than 3 participants, the course cannot take place.

Discord Server for fast Communication

Discord has been proven as a very effective platform for information sharing, discussions, and consultations. Therefore, please join the ArchiLab Discord Server at https://discord.gg/YYNYb5whU8. Navigate to channel #rollenzuweisung and click on cex. Then you automatically get access to the channel(s) relevant for this module.

Content

• Learning Outcome
• Organization
  • Phase 1: Research
  • Phase 2: Coding
  • Time budget
• Topic List
  • Kickoff Feedback to the Topics
  • How to choose?
• Grading (Based on a Points Scale Between 0 and 3)
  • Individual Contribution
• Workshops "Research Phase"
  • Fri 05.04.2024, 10:00 - 14:00: Kickoff
  • Fri 03.05.2024, 10:00 - 17:00: Do's and Don'ts for Scientific Work in Software Engineering
  • Fri 24.05.2024, 10:00 - 17:00: Research Presentations & Planning for Coding Phase
• Workshops "Coding Phase"
  • Fri 05.07.2024, 10:00 - 15:30: The Art of a Good Software Demo
  • Fri 02.08.2024, 10:00 - 14:15: Final (Coding) presentations

Learning Outcome

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 ...

• staying up-to-date with cutting edge trends in the software industry and the developer community, and therefore,
• being able to identify interesting trends and subjects,
• analyzing and researching sources that assess these trends (and by being able to prioritize such sources according to their respective standing the software community),
• designing my own hands-on proof-of-concept projects, thus being able to prove or disprove some hypothesis on my own or in a small team,
• performing a criteria-based assessment, based both on research and hands-on trial,
• summing up my results in a compact and easy-to-understand way for my peers and superiors, nature),

so that I so that I have a fact-based way of making up my mind in the VUCA world of professional software development.

Organization

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:

1. Solid, scientifically sound research, based on academic papers, books, and/or well-respected online resources, and
2. A validation of this theoretical foundation, consisting of “hands-on” coding a prototype or proof of concept.

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.

Phase 1: Research

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:

1. A research paper describing the your results. This paper must keep adhere to professional standards, i.e. it needs to have an abstract, introduction, research question, foundational research, and a literature section. Consider this paper as something you would write as an answer to an information request by the management board, or a very short version of a Master thesis, if you like this better.
   • The paper should have ca. 5-10 pages per person contributing to it (table of content, bibliography etc. not included). The page numbers are a rule of thumb, rather than a hard criterion. These numbers heavily depend on the page format, and are no indicator of quality. So, please write a nice, slim, concise paper with compact and precise wording - rather than a boring monstrosity padded with un-original mainstrain clichés, and meaningless page-long figures or code fragments.
   • It must describe the research, and contain a section where the setup for the coding experiment is explained.
2. A research presentation of the paper’s content.

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.

Phase 2: Coding

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:

1. A publically accessible repository with the code of your coding experiment
2. An addition to the research paper, marked as “part II”, describing the outcome of the software experiment and in which way it helped answering the question
3. A final presentation of your results

Time budget

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

Topic List

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	Different schools of TDD, and their impact on AI-supported software development	Konrad Fögen	ThoughtWorks	Test-Driven Design (TDD) is a software development approach where test cases are defined and written before the actual code is developed, to guide and validate the coding process. There are different schools of TDD (Mockist, Outside-In, BDD, etc.). AI tools like ChatGPT and Github have become a disruptive force in the software industry. Many expert fear that their massive use will have negative effects on the code quality. In this topic, we will analyze if the combination of TDD and AI will lead to better code quality and perhaps even faster development that using AI tools “standalone”. Students will work out the main differences between TDD schools, select 2 or more schools, and then apply them to software development supported by AI tools. The resulting code is compared to code developed with “only” AI-supported, e.g. using static analysis and metrics like coupling/cohesion or a qualitative discussion.	Pitch Video
2	eBPF: The silver bullet in container network communication?	Christian Kaubisch	christian-kaubisch.de	eBPF is a technology based on the Berkeley Packet Filter (BPF) that extends it to run a sandbox in the Linux kernel (from version 4.8) without modifying the kernel. This is achieved by using ‘hooks’ that can be applied to system calls, network events and more. The technology is already being actively used by pioneers such as Netflix and Microsoft, among others. For this CEX topic, we look at a potential application in container orchestration. We focus on the network-related layer: What problem does eBPF solve? How does its use affect safety and performance? Are there any alternatives available? Is it, overall, sensible to use it with container orchestrators?	Pitch Video
3	Does Spring Modulith lead to a cleaner architecture - or just to more boiler plate?	Stefan Bente	-	The Spring Modulith framework, in conjunction with jMolecules, is an attempt to ensure architectural integrity of large software systems. Amongst the most crucial properties of large systems is a clean cut between different sub-domains, or modules, which can then be loosely coupled, and have no cyclic dependencies. In this topic, the background, benefits, and drawbacks of this approach need to be researched, and then put to the test with a concrete (complex enough) example domain.	Pitch Video
4	Are the “concentric circles” architecture models ultimately all the same?	Gulmariyam Yerzhanova & Axel Burghof	Accso	In Domain-Driven Design (DDD), architectural styles like Hexagonal, Onion, and Clean Architecture have become popular. These designs separate business complexity from technical implementation by focusing technical dependencies in specific areas and structuring business implementation extensively. DDD facilitates this with principles, methods, and patterns to manage complexity and clearly reflect the domain in the software architecture. Key questions to explore include the development and differences of these architectures, common issues in their use, and their suitability for various applications.	Pitch Video (please use the English subtitles)
6	JHipster: The swiss army knife for DDDers?	Stefan Bente	-	JHipster claims to be a pretty universal full-stack framework for designing complete client-server applications, including configurations for deployments as microservice applications. It claims to be fairly technology-agnostic. In this topic, this approach will be analyzed and tested in a real-life application.	No pitch video available, but here is a quick intro, or have a look at the dedicated JHipster Virtual Meetup series.

(Topic no. 5 was withdrawn.)

Kickoff Feedback to the Topics

In the kickoff workshop, we collected questions and suggestions for each of the topics. See the documented post-its below.

How to choose?

There is a survey on Xoyondo (https://xoyondo.com/dp/k4gaon4mawfmjnw) 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.)

• Please vote YES for your “first choice” topic(s).
• MAYBE for topics you would accept, if your first choices are overbooked.
• NO for topics you really don’t want to do.

You need to pick your choices until registration deadline (05.04.2024). 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.

Grading (Based on a Points Scale Between 0 and 3)

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.

Individual Contribution

As a default, I assume that each team member contributes an equal share to the team project. However, if I have indications that this is not the case, I reserve the right to adjust the individual grades accordingly. In such a case, I will modify the team points for the individual score according to the following table.

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.	The student was only involved in team interactions on a few occasions.	The student has been visible to an average degree in the team (guiding others, leadership tasks, providing assistance, contributing to professional discussions, etc).	The student has been exceptionally visible in the team through guidance of others, leadership roles, assistance, contributions to professional discussions, and the like.

Workshops "Research Phase"

Fri 05.04.2024, 10:00 - 14:00: Kickoff

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.

Workshop Location

Room: 0502 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.

Goal of the day

You can start with working on this module.

Agenda

• 10:00 - 10:30:  Intro
  • Goal of this module
  • Structure
  • Organizational details
  • Grading
• 10:30 - 12:00:  Topic presentation
  • Possible topics are presented either "live" or using a short video
  • Afterwards, you have time to discuss, form subteams, and vote for your 1st / 2nd / 3rd choice
• 12:00 - 13:00:  Lunch Break
• 13:00 - 14:00:  Project planning and research
  • You meet in your subteams, and set up your own working mode
  • You set up an informal milestone plan for your work and assign todos - make sure to cover documentation, code management, and task tracking
  • Afterwards we meet and compare (each subteam briefly presents its plan)

Task until next workshop

• Finalize and organize your topic team, and start working
• make individual, bi-weekly jour fixe appointments with the supervisors (topic mentor and Prof. Bente), to track progress and discuss questions

Fri 03.05.2024, 10:00 - 17:00: Do's and Don'ts for Scientific Work in Software Engineering

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.

Workshop Location

Room: 0502 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.

Goal of the day

You and your team mates have clarified all open issues with regard to writing a coding-oriented research paper.

Agenda

• 10:00 - 10:30:  Introduction to Scientific Work in Software Engineering
  • What is this? Why is it important?
  • What do I need this for (I don't plan for a PhD)?
  • Patterns and definitions
• 10:30 - 11:30:  Research Question / Hypothesis
  • Definition
  • What makes a good research question / hypothesis?
  • Subteams - Formulate a research question for your topic
  • Comparison of results in the whole group
• 11:30 - 14:15:  Literature Research
  • Research tools and how to use them
  • Suitable sources, controversy, (involuntary) plagiarism
  • Subteams share their way of managing and assessing their sources
  • Comparison of results in the whole group
  • Then, subteams try to complete their literature research
  • Comparison of results in the whole group
  • In between - lunch break
• 14:15 - 15:30:  Designing Your Code Experiment / Proof-of-Concept
  • Definition, do's and don'ts
  • Subteams discuss their coding experiment setup
  • Comparison of results in the whole group
• 15:30 - 16:15:  Structuring Your Paper
  • Necessary parts of a scientific paper
  • Subteams create their ToC
  • Comparison of results in the whole group
• 16:15 - 16:30:  Wrapup and next steps

Task until next workshop

• Finalize your paper
• Prepare the research presentation

Fri 24.05.2024, 10:00 - 17:00: Research Presentations & Planning for Coding Phase

Each team presents its research results and the setup for their coding phase. There may also be a guest lecture on a specific topic.

Workshop Location

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/64374849021?pwd=NzkvMTdLbGlHZzFEenZoUG5CYy84Zz09

Goal of the day

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.

Video recording

• Recording part 1 (Password: 3Xe5&&nc).
• Recording part 2 (Password: 895Sk@Cn).
• Recording part 3 (Password: 895Sk@Cn).

Agenda

• 10:00 - 10:45:  (4) Are the "concentric circles" architecture models ultimately all the same?
• 10:45 - 11:45:  (2) eBPF - The silver bullet in container network communication?
• 11:45 - 12:15:  (3) Does Spring Modulith lead to a cleaner architecture - or just to more boiler plate?
• 12:15 - 13:15:  Lunch Break
• 13:15 - 14:15:  (1) Different schools of TDD, and their impact on AI-supported software development
• 14:15 - 15:00:  (6) JHipster - The swiss army knife for DDDers?
• 15:00 - 15:15:  Conclusion and next steps
  • Questions on paper finalization and submission
  • Planning for the coding phase

Task until next workshop

• Incorporate feedback into your paper
• Submit your paper
• Set up your coding experiment, and start working

Workshops "Coding Phase"

Fri 05.07.2024, 10:00 - 15:30: The Art of a Good Software Demo

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.

Workshop Location

Room: 0502 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.

Goal of the day

You have a script for your final demo, and you and your team mates have clarified all open issues with regard your coding experiment.

Video recording

A video recording is available here. (Password: Z+2*2AHQ).

Agenda

• 10:00 - 10:45:  How to properly prepare a software demo
  • Short lecture and discussions on how to properly prepare a software demo (writing a script, Do's and Don'ts, etc.)
  • Discussion
• 10:45 - 12:15:  Development of the storyboard for the final presentation
  • Each team works on their storyboard
  • Missing functionality is mocked
  • Discussion
• 12:15 - 13:15:  Lunch Break
• 13:15 - 14:30:  Dry Runs of the software demos
  • Each team presents a dry run of their demo
  • The team gets feedback from the other teams
• 14:30 - 15:30:  Discussion of open issues in coding experiments, wrapup and next steps
  • Any open issues in the coding experiments are discussed
  • Wrapup and next steps

Task until next workshop

• Finalize your coding experiment
• Prepare the final presentation

Fri 02.08.2024, 10:00 - 14:15: Final (Coding) presentations

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.

Workshop Location

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/64374849021?pwd=NzkvMTdLbGlHZzFEenZoUG5CYy84Zz09

Goal of the day

Presenting your team's final results from the code experiment, and getting feedback from peers and supervisor.

Video recording

There will be a video recording of the relevant parts available afterwards, in case you are not available at that time.

Agenda

• 10:00 - 10:45:  (1) Different schools of TDD, and their impact on AI-supported software development
  • See this link for the recording (password B@5!4uct)
• 10:45 - 11:30:  (2) eBPF - The silver bullet in container network communication?
  • See this link for the recording (password B@5!4uct)
• 11:30 - 12:15:  (4) Are the "concentric circles" architecture models ultimately all the same?
  • See this link for the recording (password B@5!4uct)
• 12:12 - 13:15:  Lunch Break
• 13:15 - 14:00:  (6) JHipster - The swiss army knife for DDDers?
  • See this link for the recording (password .u&&Q29H)
• 14:00 - 14:15:  Conclusion and next steps
  • Questions on paper finalization and submission
  • Planning for the coding phase

Task until next workshop

• Incorporate feedback into your paper
• Submit your paper