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

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

Room 2: Innovation Hub (Building LC7, the building to the right of the passage to Gummersbach station. The Innovation Hub is not not open to the public. However, the main entrance door is open during office hours. Come up to the second floor and ring the bell there. Please call me (+49 176 8072 2689) or a fellow student by cell phone if no one answers), see also detailed directions

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

ILIAS/ILU 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/ILU course. Deadline is 03.10.2022. 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 15. 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
  • How to choose?
• Grading
• Workshops
  • Tue 04.10.2022, 10:00 - 14:00: Kickoff
  • Tue 18.10.2022, 14:00 - 15:00: Research Status no. 1
  • Tue 01.11.2022, 10:00 - 12:00: Research Status no. 2
  • Tue 15.11.2022, 10:00 - 12:00: Research Status no. 3
  • Tue 29.11.2022, 10:00 - 16:00: Research presentations & planning for coding phase
  • Tue 20.12.2022, 10:00 - 12:00: Coding Status no. 1
  • Tue 10.01.2023, 10:00 - 12:00: Coding Status no. 2
  • Tue 24.01.2023, 10:00 - 12:00: Coding Status no. 3
  • Fri 10.02.2023, 13:00 - 17:00: 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. 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), 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

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), see also detailed directions. 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.

Video recording

A video recording is available here. You know the password.

Agenda

• 10:00 - 10:45:  Guest Lecture - Static Code Analysis with SonarQube
  • By Axel Burghof - Software Dev, Agile Enthusiast, Method Lead, Managing Consultant at Accso. Exited to bring powerful methods, technology and people to customers.
  • Facts about the development work? More time for the essentials in code reviews? Do you want to improve code quality in a targeted manner? SonarQube can support us in all of this as a central tool.
  • As a freely available "Swiss army knife", SonarQube analyzes the source code of different languages for compliance with conventions and best practices, functional or security problems as well as various code metrics.
  • All measured values can be evaluated manually via SonarQube's web interface, from summary to detail. Quality profiles and threshold values can be used to set how the result is to be evaluated from a Continuous Integration perspective.
  • In this guest lecture, Axel will share Accso's experiences with SonarQube in a project, and looks forward to answering your questions about the possible implementation in your own project(s).
• 11:00 - 11:30:  AI-supported code completion (research presentation)
• 11:30 - 11:50:  Code signatures for plagiarism detection (research presentation)
• 12:00 - 12:30:  Bridging the Type Gap - Do Protobuffers reduce the error rate in full-stack development? (research presentation)
• 12:30 - 13:30:  Lunch Break
• 13:30 - 13:45:  Good Practices for Documentation as Code (research presentation)
• 13:45 - 14:05:  Domain Specific Languages - Which problems are worth developing a DSL to solve them? (research presentation)
• 14:15 - 14:45:  Sync vs. async APIs - and when to use what (research presentation)
• 14:45 - 15:00:  Wrapup and next steps

Task until next workshop

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

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

Fri 10.02.2023, 13:00 - 17:00: Coding presentations

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

Workshop Location

Room: Innovation Hub (Building LC7, the building to the right of the passage to Gummersbach station. The Innovation Hub is not not open to the public. However, the main entrance door is open during office hours. Come up to the second floor and ring the bell there. Please call me (+49 176 8072 2689) or a fellow student by cell phone if no one answers), see also detailed directions. In addition, there is a video conference. Video conference link: https://th-koeln.zoom.us/j/88028307460?pwd=ZTlDcUx6aTUwWXlYaXNndm1tbWs2Zz09

Video recording

A video recording is available here. You know the password.

Agenda

• 13:00 - 13:45:  AI-supported code completion
  • What are the possibilities and limitations of AI technology as of today, in supporting the coding process?
  • What are GitHub Copilot, Tabnine, Visual Studio Intellisense and other competitors able to do - and where are their limits?
• 13:45 - 14:15:  How to use code signatures for plagiarism detection
  • 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?
  • This question is highly significant in academic software engineering education, to prevent fraud and plagiarísm in exercises and tests.
• 14:15 - 15:00:  Bridging the Type Gap - Do Protobuffers reduce the error rate in full-stack development?
  • 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?
• 15:00 - 15:15:  Break
• 15:15 - 15:45:  Good Practices for Documentation as Code
  • Developers often struggle to write documentation of their work - partly because it seems to be 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.
  • How much should be documented depending on the type of project ? Which tools are available ? How should an integration with CI/CD look like?
• 15:45 - 16:15:  Domain Specific Languages - Which problems are worth developing a DSL to solve them?
  • A software engineer, when it comes to complex domains, could develop a DSL rather than a final solution. Such a DSL could be used by domain experts to provide and evolve their own solutions for such problems.
  • Which problems are worth developing a DSL to solve them? Which are the pros and the cons of such a technique ? Which tools can help in building one ?
• 16:15 - 17:00:  Sync vs. async APIs - and when to use what (research presentation)
  • This is also known as the REST vs. Kafka challenge. Can we formulate patterns and recommendations for situations where one option makes more sense than the other?
  • As base domain, a simple eCommerce application has been developed.
  • This application has been used to take a deeper look at relevant questions, like publishing snapshots of business objects vs. just the delta, typed or typeless events, who owns the schema, how to deal with schema changes, choreography vs. orchestration, etc.