All Posts

Can We Breed Software Leaders, Faster?

_images/P4.SportyManyStars.jpeg

reading-time:

15min

As the software industry continues to flourish, so does the need for mature leaders. In this evolving landscape, two primary goals emerge: motivating and supporting current (entry-level) leaders to grow and breeding a new generation of leaders. As seen in ‘Leading Technical Software Development is Hard! We Must Improve’, the software engineering landscape is evolving rapidly, increasing the demand for more engineers, and consequently, more leaders are needed. At the same time, Scrum (particularly Scrum) has led to smaller teams, making natural leadership progression harder; see ‘Did Scrum Kill the Leadership Route?’. We also have studied some cases in ‘No leaders, no appeal!’, showing what might happen when no experienced leaders are available.

In this blog, we will explore several well-known leadership development approaches, examine how to apply them in software development and determine if we can expedite the process.

Read more ...


No leaders, no appeal!

_images/P3.WorkOnComputer.jpeg

reading-time:

11min

After some theoretical reflections in ‘Leading Technical Software Development is Hard! We Must Improve’ and ‘Did Scrum Kill the Leadership Route?’ it is time for some real-world examples.
What can go wrong without mature leadership?

Read more ...


Did Scrum Kill the Leadership Route?

_images/P2.WhatWhenHow.jpeg

reading-time:

6min

Scrum and other Agile methodologies have revolutionised software development, bringing many benefits like improved flexibility and faster delivery. However, they are not without drawbacks. Scrum, with a focus on short-term goals, has the drawback that long-term objectives may seem less important. This may become a significant issue for complex embedded systems. For big projects, with huge codebases and many developers, the importance of (short-term) sprint goals and (long-term) architecture will conflict. Other long-term objectives may have similar issues.

As we have seen in ‘Leading Technical Software Development is Hard! We Must Improve’ leadership is becoming more important, and that the natural growth path for future leaders —in three axes (What, When & How)— has partly vanished. Maybe for the same reason.
In this article, we study whether Scrum did have this undocumented, unintentional negative effect. Later, we will show how to compensate for this.

Read more ...


Leading Technical Software Development is Hard! We Must Improve

_images/P1.DarkPositive_BigTeam_Zandloper.jpeg

reading-time:

8min

As embedded systems and technical software are becoming larger and larger, as well as more complex, leading those massive projects and teams is more vital than ever—and increasingly challenging. Engineers need substantial experience to lead these projects effectively. However, paradoxically, people seem to have less and less experience in working in big teams.

Adding to this dilemma are the typical role names for senior leadership, which are inflating. For example, every (little) team nowadays has a software ‘architect’, whereas that role was called (senior) developer before. As a result, when one needs a ‘real architect’ one is flooded by juniors. Similarly, a ScrumMaster —once the agile, facilitating project leader— is now often just a side-activity for a programmer.
But then who is overseeing a scope bigger than a few sprints? Is somebody in charge at the tactical level?

As a side effect, this blocks the desire to grow: many modern architects and ScrumMasters assume they are on top of the world already. In this blog, I describe the need for those leaders and what they need.

Read more ...


An Agile SIA

The SIA – an acronym for System (or Software) Impact Analysis – is an often used approach to get insight into the costs, risks, and possibilities of implementing a feature. It should result in a readable document to decide whether it adds value to implement that feature and offer options on how
But is also a document that is repeatedly incorrectly used.

The classical SIA isn’t very Lean nor Agile; certainly not when it became an (upfront) design document, as often …
On second thought, a good SIA is lean and agile. A short, up-front “think ahead” document makes it possible to postpone details to future sprints and assist the Product Owner in picking the right solution without adding costs.

Let’s study how we can write an Agile SIA. One with business value.

Read more ...


Agile System Architecting

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 …

Read more ...


Applying BDD & TDD in legacy

reading-time:

8m45

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?’

Read more ...


Introducing BDD & TDD

reading-time:

5m30

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.

Read more ...


The Never-ending Struggle on CodeQuality due to the growth of teams and codebases

reading-time:

6m

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.

Read more ...


Why Modern Embedded Software Systems nowadays embrace webserver-technology

reading-time:

3m45

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?
And why?

Read more ...


Pub/Sub

practice-time:

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 RealTime!
But, by knowing how to implement it and are able to design it, will help you to use it for the better

Read more ...


ThreadPoolExecutor

practice-time:

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.

Read more ...


Requirements Traceability

study-time:

1 hour

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.

Read more ...


De Embedded Linux Expert bestaat niet

reading-time:

4 minuten

Regelmatig krijg ik ‘Embedded Linux Experts’ aangeboden; bijvoorbeeld voor het HTLD-team (HighTech Linux Delivery). Vaak zijn goede mensen, met Linux ervaring; maar toch niet de mensen die ik zoek. Het blijkt erg lastig voor niet direct betrokken, om de juiste experts te spotten. Daarom een paar hints waarmee je “de” Embedded Linux Expert herkent. Immers, alleen het woordje ‘Linux’ op een CV is onvoldoende!

Read more ...


dPID: A Python ‘homework’ exercise

practice-time:

1 hour

This is an optional exercise for the python-3 workshops: program a discrete PID-controller.

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

Read more ...