Coding Excellence (CEX), WS22

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
04.10.2022 - 28.02.2023. Organized as ca. 8 half-day or full-day workshops (Tuesdays), specific dates and agenda see below.
Location
The module takes place in a hybrid format. Please refer to the respective time slot or workshop day (see below on this page), to check if it is online or in presence. If there are no details given on this page, please check the other communication channels (e.g. Discord).
Video conference link: https://th-koeln.zoom.us/j/88028307460?pwd=ZTlDcUx6aTUwWXlYaXNndm1tbWs2Zz09
Room: 0504 (Building LC6, opposite main entrance of Schwalbe Arena)
ILIAS Course for the Module
https://ilias.th-koeln.de/ilias.php?ref_id=2318810&cmdClass=ilrepositorygui&cmdNode=wc&baseClass=ilrepositorygui
Registration for the Module
Please join this ILIAS course. Registration is possible until 03.10.2022. The maximum number of participants is 15. If there are less than 3 participants the event cannot take place. 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.
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 see all channel(s) relevant for this module.

Content

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

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. 10-15 pages per person contributing to it (just as a rule of thumb). Table of content, bibliography etc. not included.
    • 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 (29.11.)

Deadline for paper submission is 02.12. (eod), so you can still take feedback from the presentations into account. I will grade the paper as submitted. The paper will be enhance 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
  4. An individual 15 min oral colloquium about your research and coding project

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
  Status Workshops 6
  Meetings with topic sponsor (recommended every two weeks) 4
  Coordination meetings within team 4
  Research & paper writing 40
  Designing the coding experiment 12
  Preparing the research presentation 12
  Presentation & Planning Workshop 6
Coding Phase Status Workshops 6
  Meetings with topic sponsor (recommended every two weeks) 4
  Coordination meetings within team 4
  Coding 40
  Documentation of coding results 16
  Preparing the final presentation 12
  Final Presentation Workshop 6
  Individual oral colloquium with preparation 4
Total Effort   180

Topic List

No. Topic Sponsor Organization Additional Information Team Size Brief motivation
1 AI-supported code completion Stefan Bente TH Köln What are the possibilities and limitations of this technology as of today? What are GitHub Copilot, Tabnine, Visual Studio Intellisense and other competitors able to do - and where are their limits? 1-3 Live in kickoff workshop 04.10.22
2 Bridging the Type Gap: Do Protobuffers reduce the error rate in full-stack development? Kjeld Schmidt ThoughtWorks “Protocol Buffers” are a tool to define structured data once in a special configuration format, serialising it and communicating between various language runtimes. In Frontend-Backend-communication, a common approach in modern development is to communicate with json-encoded data, with the structure of the data frequently being declared in documentation rather than living code - frontend and backend independently define the data type and (de)serialization process. Changing the implementation on only one end can easily lead to a situation where the happy path causes no errors and edge case issues are detected later, when the context of a change might have been forgotten. Can protocol buffers be applied to create a more consistent developer experience, in which potential misalignment is discovered earlier and fewer bugs are deployed to a live system? 1-3 Motivational video
3 Code signatures for plagiarism detection Stefan Bente TH Köln In the age of ubiquitous open source, code plagiarism is easy - just copy a piece of code, maybe change it here and there, and include it into your own code base. But ultimately, coding is a bit like hand-writing. What ways are there to compare two code bases for plagiarism, using code signatures or other means? 1-3 Live in kickoff workshop 04.10.22
4 Different schools of TDD (Inside-Out, Outside-In, …) and their impact on design of code and tests Konrad Fögen ThoughtWorks Students identify different schools of TDD, work out differences, select 2 or more schools, apply them to examples (e.g. coding katas), and finally work out differences in the application source code and tests (e.g. using static analysis and metrics like coupling/cohesion or a qualitative discussion). 1-3 Motivational video
5 JHipster - the swiss army knife for DDDers? Stefan Bente / René Wörzberger TH Köln JHipster claims to be a pretty universal full-stack framework for designing complete client-server applications, including configurations for deployments as microservice applications. In this topic, JHipster will be compare to a more traditional approach (e.g. Java/Spring/Angular) and with a real-life code base. 1-3 Live in kickoff workshop 04.10.22
6 Sync vs async APIs and when to use what Wolf Schlegel ThoughtWorks A.k.a. the REST vs. Kafka challenge. Can we formulate patterns and recommendations for situations where one option makes more sense than the other? We have two sub-topics here, each can be worked on by a separate subteam. The base domain code for the coding experiment can (to some degree) be provided by Wolf.

6a. Event schemas
- Publish snapshots of business objects or just the delta?
- Typed or typeless events?
- Who owns the schema?
- How to deal with schema changes, in particular breaking changes?
- Who validates, sender and/or receiver?

6b. Choreography vs orchestration
- How much control over processing flow is needed?
- Asynchronous request-response or “just” publishing things?
- How to understand the current distributed state e.g. of an order?
- Centralised vs distributed order status?
4-6 Motivational video (in German), slides
7 Domain Specific Languages - Which problems are worth developing a DSL to solve them? José Pinar ThoughtWorks It feels that the role of a software engineer, when it comes to complex domains, could be to develop a DSL rather than a final solution. Such a DSL could be used by Software Engineers, Domain experts with programming skills, or both, to provide and evolve solutions for such problems. A good material is also the book from Martin Fowler. The questions I can think of are: Which problems are worth developing a DSL to solve them? Which are the pros and the cons of such a technique ? What is the difference between external and internal DSL ? When to use one or the other? For internal DSL, which programming languages facilitate them and which patterns are available ? For external DSL , which skills and theoretical knowledge is needed (from grammars, normalizations, etc) and which tools can help in building one ? 1-3 Motivational video
8 Good Practices for Documentation as Code José Pinar ThoughtWorks Developers struggle to write documentation of their work and part of it is that it seems an unrelated task that is separate from coding solutions. Bringing the documentation and part of the development process, together with the “executable” code might help having more up to date documentation. Different projects have different needs, and therefore the stress on certain types of documentation would be different. For some projects it might be sufficient with some Markdown files, starting with a README.MD that would make the project easier to understand for new developers. Other projects might need to generate architecture diagrams, manuals or other type of artifacts that might be consumed beyond the developers. In that sense the final version of the documentation might be incorporated to the CI/CD pipelines. Questions would be: How much to document depending on the type of project ? Which tools are available ? Integrations with CI/C ? Does this approach facilitate compliance in regulated industries like healthcare and automotive ? 1-3 -

How to choose?

There are two surveys open:

  1. Please book your main preference here. You need to decide for one topic. There is also a “none of the above” option - I might have additional topics in the pipeline, but there is no guarantee for them.
  2. In addition, please also book your secondary choices - if your first choice is overbooked, and I need to randomly decide, what other topics would also work for you?

Grading

The module grade consists of several partial grades for the artifacts listed above.

Artifact Percentage Criteria
Research paper describing the your results 30% - Sound research (appropriate resources found & evaluated)
- Appropriate effort & commitment
- Code experiment makes sense and fits to the research question
- Editorial & format aspects (citations, chapter structure, grammar, spelling)
Research presentation 7,5% - Completeness (all results covered)
- Understandable and vivid style
Repository with the code of your coding experiment 25% - Code experiment well implemented
- Enough documentation to understand the code (and to repeat running it)
Part II of the research paper describing the outcome of the software experiment 10% see “research paper”
Final presentation of your results 7,5% - Completeness (all results covered)
- Interesting demo of your code
Individual 15 min oral colloquium 20% - Student can explain all aspects of her/his own topic
Sum 100%  

Workshops

Tue 04.10.2022, 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: 0504 (Building LC6, opposite main entrance of Schwalbe Arena).

Goal of the day

You can start with working on this module.

Agenda

Task until next workshop

Tue 18.10.2022, 14:00 - 15:00: Research Status no. 1

We make a quick round through all the teams, and discuss progress and obstacles.

Workshop Location

Video conference link: https://th-koeln.zoom.us/j/88028307460?pwd=ZTlDcUx6aTUwWXlYaXNndm1tbWs2Zz09 .

Tue 01.11.2022, 10:00 - 12:00: Research Status no. 2

We make a quick round through all the teams, and discuss progress and obstacles.

Workshop Location

Video conference link: https://th-koeln.zoom.us/j/88028307460?pwd=ZTlDcUx6aTUwWXlYaXNndm1tbWs2Zz09 .

Tue 15.11.2022, 10:00 - 12:00: Research Status no. 3

We make a quick round through all the teams, and discuss progress and obstacles.

Workshop Location

Video conference link: https://th-koeln.zoom.us/j/88028307460?pwd=ZTlDcUx6aTUwWXlYaXNndm1tbWs2Zz09 .

Tue 29.11.2022, 10:00 - 16:00: Research presentations & planning for coding phase

On this "longer-than-usual" workshop, each team presents its research results and the setup for their coding phase.

Workshop Location

Room: 0504 (Building LC6, opposite main entrance of Schwalbe Arena). In addition, there is a video conference. Video conference link: https://th-koeln.zoom.us/j/88028307460?pwd=ZTlDcUx6aTUwWXlYaXNndm1tbWs2Zz09

Goal of the day

Getting feedback to my own research.

Agenda

Task until next workshop

Tue 20.12.2022, 10:00 - 12:00: Coding Status no. 1

We make a quick round through all the teams, and discuss progress and obstacles.

Workshop Location

Video conference link: https://th-koeln.zoom.us/j/88028307460?pwd=ZTlDcUx6aTUwWXlYaXNndm1tbWs2Zz09 .

Tue 10.01.2023, 10:00 - 12:00: Coding Status no. 2

We make a quick round through all the teams, and discuss progress and obstacles.

Workshop Location

Video conference link: https://th-koeln.zoom.us/j/88028307460?pwd=ZTlDcUx6aTUwWXlYaXNndm1tbWs2Zz09 .

Tue 24.01.2023, 10:00 - 12:00: Coding presentations

Final presentation of the overall project and its results. Open to guests from outside the project.

Workshop Location

Room: 0504 (Building LC6, opposite main entrance of Schwalbe Arena).