EN 
DE 
MicroConsult trainer and project coach Frank Listing on Clean Code and how he envisions the ideal workflow of an embedded project.
What does a trainer in the field of embedded software deal with on a daily basis?
Frank Listing: It quickly becomes apparent that software still holds a low priority in German mechanical engineering and automotive companies. Software is seen as something added on at the end; it can be done alongside other tasks, and changes can always be made later. But unfortunately, it's not that simple.
The current state of software development is closely linked to the success of the mechanical engineering sector in this country. This is also reflected in the educational backgrounds of developers. Programmers in the embedded systems field primarily come from electrical engineering and mechanical engineering. Only a minority of them have received more formal training in software development. Many acquire their knowledge through reading and combining it with their previous learning. However, simply mastering the syntax of a programming language is insufficient. If I don't understand the processes, algorithms, and procedures, I can't apply them. And they aren't always intuitive.
Ultimately, Germany still lacks established training structures for software programming in industry. Even at many universities, software projects are often not evaluated based on their structure, but only on the result.
Software developers who previously worked in pure mechanics or electronics are not only less well-trained for embedded programming, they also originally chose a different profession. Sometimes they aren't even particularly motivated to write good software. Very few find their new passion in it. You can imagine the result.
What can be done to get these people excited about software programming?
Frank Listing: Once you understand that writing software is a creative process that doesn't have to follow a fixed pattern, if done correctly, you can develop truly beautiful things. And we need more applications today that can solve complex tasks. This can motivate some, but not others. Even in software development, you can choose the tedious, unenjoyable path. The software might still work, but the better solutions are usually the creative ones.
A standard, run-of-the-mill education doesn't instill this passion. Consequently, the software is programmed with little foresight – which doesn't improve it over time. This leads directly to the next problem: When poorly documented software is developed in a work environment with high employee turnover, the consequences can be disastrous.
What would be the ideal workflow for an embedded project?
Frank Listing: First and foremost, it's important to think about the requirements early on. Often, teams start programming without knowing what they want to achieve. And if I don't know exactly what the end result will be, I might end up with something large and slow.
A good embedded project begins with a system design, meaning the initial idea of what the solution should look like in principle. This, of course, requires the requirements as a prerequisite for designing an architecture. The project is then split into hardware and software, the development of which largely runs in parallel.
The biggest mistake is made when hardware and software are only brought together at the very end, without first synchronizing them at least to some extent and communicating new requirements. Once the architecture is refined with a few details, we slowly begin to program. Software development is essentially the entire process from design to the end of testing. Depending on the development process, testing takes place either during implementation or shortly thereafter.
It often happens that people write code too early, without knowing enough about the requirements. Too many requirements, as well as the application's structure and architecture, are still missing, but they just start anyway. In itself, this is the slower approach. The response I usually get is: "It had to be done quickly." But it's actually faster if you think carefully beforehand about exactly what you need to implement.
What should you avoid if a project goes off track?
Frank Listing: What you don't need right now is a new tool that supposedly gets you out of this mess. A new tool introduces a new source of disruption, unless you've thoroughly evaluated and studied it beforehand and only integrate it into the project once you're completely familiar with it. So: master the programming language and know the tools you're using inside and out, otherwise things will get chaotic.
Which roles within the development team make sense?
Frank Listing: Ideally, I would have clearly defined responsibilities beforehand. You need a software architect, and everyone, including yourself, is aware that they hold this role. Depending on the project's size, there could be several architects. They, alone or with a small team, are responsible for the design. The design work is then distributed among several people, and the entire team handles the implementation. This approach provides the project with a reasonably sound structure and direction.
What else should you pay attention to beforehand?
Frank Listing: A common mistake is bringing testers in far too late. A tester should be able to assess whether the software and its architecture are even testable during the requirements phase. If they aren't, further development won't be feasible in the future. Unfortunately, the reality is that the supposedly finished software is only released for testing once it's already complete. This results in a tremendous loss of time. By involving testers earlier, problems can be identified and resolved early on. If testers are already aware of the potential issues, they can address them beforehand, making the entire project timeline much easier to maintain.
Clean Code For me, it also represents a certain aesthetic. It's not only enjoyable to look at, but it also follows certain rules, is easy to read, and contains fewer errors. This readability brings other advantages: it can be easily extended without having to modify it to add new features. This requires not only experience, but also a genuine enjoyment of programming.
The great thing is: the learning curve for software programming is relatively steep. And you can shorten it by reading a textbook or taking a course. Some mistakes you have to make yourself, other solutions you can learn from others. And usually, you then take a big step forward. Fortunately, our courses are always attended by developers who want to learn more. That makes my work much easier and more enjoyable, too.
————————————————————————————–
Improve the quality of existing source code and ensure the quality of new software projects from the outset. MicroConsult seminar on the topic of clean code Learn the most important principles, rules and practices for creating practical, maintainable software according to the ideas of "Clean Code". Register now!
Further information
MicroConsult Training: Clean Code for C Programs
MicroConsult Training & Coaching on the topic of software quality
MicroConsult expertise on the topic of software quality
