EN 
DE The software engineer as the center of industrial software development
Author: Thomas Winz, softwareimotion
Contribution – Embedded Software Engineering Congress 2015
„"Nerdy was fed up with this DinoPark project. Although they were already behind schedule, InGen demanded extensive modifications to the system but was unwilling to pay for them; management argued that this was part of the original contract. They threatened legal action."“ [Ref1]
Software is a valuable asset developed in an environment of great uncertainty. Without proper and sensible industrial software development, this tension makes any cost-benefit analysis impossible; this is precisely where eCc (embedded clean code) comes in.
introduction
Modern approaches to personnel management mean that critical project decisions are often made by individual developers in day-to-day operations. Extending decision-making authority to the entire project team carries risks. eCc's clear rules help developers focus on coding and thus consciously accept this high risk.
background
Embedded Clean Code celebrated its world premiere at the Embedded Software Engineering Congress in 2014 [Ref 2]. The eCc rule set serves as the foundation for proper and sensible industrial software development (see Figure 1, PDF).
The theory presented in 2014 comprises three major subject areas:
- Avoid unnecessary coding
- Good design is always appropriate
- It's always easier to write code than to understand it.
This volume contribution builds on these „best practice“ principles from eCc and discusses eCc’s activities this year.
Values for group work
Without trust and a shared moral foundation, people cannot collaborate. This is also the fundamental belief behind all agile methods. The activities described in eCC are practiced to prevent errors. But this means that individual developers must point out their weaknesses to the group. To do this, individual developers must build trust in their colleagues. This means that eCC methods can only be truly implemented within a healthy group culture.
However, listing these fundamental values would exceed the scope of eCc. Therefore, we will limit ourselves to listing the values of "Extreme Programming." These values have proven effective in thousands of projects since 2004 and thus provide a solid foundation for eCc.
|
Value |
Description |
| simplicity | Simplicity is a state characterized by the fact that only a few factors contribute to its emergence. |
| communication | All project members should communicate intensively with each other. Personal conversations will help to clear up misunderstandings more quickly. |
| Feedback | To achieve high quality, namely to achieve what the customer needs, very short feedback loops are used to continuously show the customer the development. |
| courage | Using these values and communicating them openly requires a great deal of courage, especially for project members who are not used to acting according to these values. |
| respect | The foundation of these values is respect; respect refers to a form of appreciation, attention and consideration towards all other team members. |
Table 1: Extreme Programming Values [Ref 3]
The basic software activities
„"When push comes to shove, trust your disciplines. The reason you have these disciplines in the first place is to give you direction in times of high pressure."“ [Ref4]
Prioritize ease of implementation.
According to ISO 26262, one goal of unit testing is to demonstrate that software does not exhibit undesired behavior [REF 5]. If desired behavior is understood as "defined by requirements," this means that any functionality without a requirement unnecessarily complicates the software and potentially compromises it. Therefore, it must be assumed that not all dependencies have been considered (see the accompanying figure)., PDF).
Leave a function in a more understandable way than when you found it.
If a function is modified after its creation, further adjustments are likely. Therefore, it is advisable to rigorously clean up these frequently used code sections to minimize the overall effort required for these modifications over the project's lifetime (see accompanying figure)., PDF).
Caution is advised when optimizing software.
Any optimization without a goal is a waste of time, as the improvement can only be measured subjectively by the individual developer. Unforeseen dependencies on other subsystems can be severely disrupted. Only static and architectural analyses can be used to justify changes (see accompanying figure)., PDF).
Never remove software carelessly
It is absurd to assume that a newly developed function is better than the existing one. On the contrary, the age of a function serves as an indicator of its quality. The function's behavior, including deviations from the requirements, is known and has already been successfully implemented multiple times. Therefore, it can be assumed that the new development will again contain known errors (see the accompanying figure)., PDF).
Live a free review culture
„…that reviews incur costs and in return receive better quality. … The truth is, you get quality and also save time.”. [“ Ref 6]
Many standards require reviews of work products, which is why a variety of review types exist. Nevertheless, this technique struggles for acceptance. It is crucial that a review process is largely automated. This includes, first and foremost, the execution. Communication, planning, and traceability should be seamless. Management must also accept that this effort can be attributed to the developer. More importantly, however, the work product should be analyzed using tools to capture simple, routine questions about it. This transforms the review into a scientific method. Personal disputes about tastes are prevented. Anonymization helps ensure that group conflicts are not aired during reviews.
Live a conservative code convention
„The modifiability of software describes the effort required to adapt it to new, future requirements.“ [Ref 7]
Modifiability is part of the non-functional requirement for software maintainability. The more an individual developer leaves their mark on the software, the greater the effort required for other developers to understand their intentions. Constructs that were otherwise understood uniformly across the entire project software must then be relearned in specific cases. This negates any added value of the individual solution. This pattern of behavior is more than just deliberate obfuscation. While it may lead to significant savings for individuals in everyday work, bug detection usually occurs under increased time pressure, meaning that this sloppy approach can become a threat to the team's survival at a crucial moment.
Periodic refactoring using static analysis
„"... debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? “ [Ref 8]
Cost-effective implementations require compromises with the existing architecture. Therefore, a systematic evaluation must be conducted periodically to determine whether the software still conforms to the architecture. Workarounds, bug fixes, and breakthroughs are identified and organized into a structured framework. It is crucial that such evaluations are mechanically supported by tools. This facilitates the uncovering of underlying structures, and a scientific approach replaces emotionally driven debates about the direction of development.
Summary
The developer bears sole responsibility for software quality and maintainability. The non-functional requirements of today's industrial software, such as fault tolerance, understandability, and portability, cannot be met without the skills of professional developers. eCc aims to provide developers with a guideline to uphold these values even under the pressures of daily development.
Legal situation regarding embedded clean code
We are looking for partners to make the rules known throughout Germany.
The eCC rulebook is published under the Creative Commons license:
CC BY NC SA :https://creativecommons.org/licenses/by-nc-sa/3.0/de/
List of sources
| Ref | Title | Author/Link |
| 1 | Dino Park | Michael Crichton |
| 2 | embedded clean code;
eseCongress 2014 |
Embedded Clean Code |
| 3 | https://en.wikipedia.org/wiki/Extreme_programming | |
| 4 | Clean Coder Code of Conduct for Professional Programmers | Robert C. Martin |
| 5 | INTERNATIONAL
STANDARD Road vehicles — Functional safety
|
ISO 26262-1
First edition 2011-11-15 |
| 6 | Popular misconceptions and misjudgments in review techniques | Peter Rösler |
| 7 | https://de.wikipedia.org/wiki/Modifizierbarkeit | |
| 8 | „The Elements of Programming Style“, 2nd edition, chapter 2 | Brian Kernighan
|
Agile & Scrum – our training & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of Agile & Scrum.
Training & coaching on the other topics in our portfolio can be found here. here.
Agile & Scrum – Expertise
Valuable expertise on the topic of Agile & Scrum is available here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
