Posts in English
There always has been some anarchy about the architect’s role –and even more distraction when we combine it with software and/or system. I’m not going to solve that. Not today …
As I described in Introducing BDD & TDD, understanding the common goals of Behavior & Test Driven Development
and defining your specific needs is the first and most critical step to start using this essential discipline.
Whenever the goal is to use new tools, it is simple: purchase them, shop for some hands-on training, and you are done.
Our ambition is different: we want to become Agile and Lean.
Then, it depends on the starting point too. B&TDD in greenfield development is relatively simple: start writing your tests and code!
However, starting with B&TDD in (Modern) Embedded Software can be more challenging due to the existing and often
extensive codebase that was developed before the emergence of B&TDD.
Then, the question ‘How to start?’ is more like ’How to get out of the waterfall?’
Is Behavior & Test Driven Development an essential aspect of professional software engineering? Leaders such as
#UncleBob compare it to ‘double entry bookkeeping’: a crucial discipline. He claims that when our industry doesn’t
professionalize quickly, we have the risk that B&TDD will be enforced by law (too).
So, it can be wise to learn to practice it quickly.
It is not easy to start when writing (long-lasting) embedded systems. We have other demands, codebases with a
lot of history. Still, we can (& should).
And we have an advantage, our Typically engineers are clever: When they understand the objectives, they will find a solution; that is their job!
Updated on 2020/07/15
This old article was never really published. As it fits my new MESS blogs, I reworked and posted it again. This is part-I; I expect other parts coming weeks.
As your embedded software codebase grows, the risk of introducing errors and bugs increases exponentially. Doubling
the number of developers will roughly double the risk of mistakes. We need new “tricks” to strive for the
ever-demanded high quality.
This is a constant battle. As embracing tools, processes, or disciplines helps only once.
Whether it’s your office printer, your internet router at home, or your future top-notch embedded system, they all
use technologies that, only a decade ago, nobody imagined using in an embedded system! How did this happen?
2 * 1 hour
The publish-subscribe architecture-pattern is very popular to route messages, according to WikiPedia. It is used much more generic, however. This workshop shows how
to use it in an embedded application, or another single process application.
Then it becomes a HighTech (embedded) software design pattern.
We start with a simple implementation of Pub/Sub. You can experiment with that (Python) code and/or port it to your favorite language. Then, you are asked to design a cached, distributed version. Which is a bit more ambitious. And even though the result is probably pointless, it’s a great Design-Exercise and a lot of fun!
It will help you to understand Pub/Sub, help you to use it in embedded software. Eventually, you may need Pub/Sub in a
distributed environment. Then, it is better to use one of the existing ones, like DDS (Data Distribution Service); which more efficient and even
But, by knowing how to implement it and are able to design it, will help you to use it for the better
2 * 1 hour
This workshop is about the ThreadPoolExecutor (‘TPE’ for friends): a pool of workers implemented with Threads. This is a modern, advanced design-pattern available in many languages.
You will get an introduction to the concepts, to be able to use the ‘TPE’. Also, we study Python implementation, to practice design-analyse.
Requirement-Management, and especially “Tracking Requirements” isn’t that complicated, but it needs some discipline. Often that discipline is replaced by a tool, which is encouraged by tool-vendors. That hardly ever works.
This blog introduces requirements traceability in a conceptual, but pragmatic way. It shows –as a demo– what a team has to do (defining requirements and describing the relations) and what the benefit is. It assumes a (more or less) agile way-of-work and shows how it can become lean. A small investment in good requirements definitions makes validations a lot easier.
And yes, it used a tool: a free one; as part of the documentation-system that is used for this side. An structured,
version-controllable, textual way to write documentation, including all requirements. With a plugin that
can visualize all specifications and their relations.
Those “particulars” will be shown too.
This is an optional exercise for the python-3 workshops: program a discrete PID-controller.
class definition is given; which has to be tested and implemented. By starting
with the test-part, which is advisable anyhow (the TDD approach), the exercise starts simple.