Episode 28: Burkhard on Qt Embedded Systems

Welcome to Episode 28 of My Newsletter on Qt Embedded Systems

This will be the last episode of my newsletter. From now on, I'll do all my writing on my blog. So, you won't have to do without my thoughts, analyses, summaries and reviews from my newsletters. 
I was pondering this decision for a couple of months. I made up my mind after reading Why You Might Want To Leave Your Content Ungated by David C. Baker. Without doubt, newsletters are gated content. The two days, which I typically spent on writing an episode, didn't help me attract more readers to my blog and vice versa. I spread myself thin as a solopreneur. 
I am proud that 450 people find my writing valuable. I thank you for that 🙏 I'd be happy if you connected with me on LinkedIn or Twitter (see the buttons at the end of this email). 
 
Thank you, enjoy reading and take care - Burkhard 💜

My Posts

Visualising the Architecture of Qt Embedded Systems: Context and Container Diagrams

Simon Brown created a simple and flexible notation with the C4 diagrams. The same diagrams can be used on four levels - adapted to Qt embedded systems:

• Context level: Interactions of the Qt embedded system with other systems or persons like the IoT Cloud, the machine and the operator. 

• Container level: Interactions of runnable units (containers) - applications and services - like the media, radio and navigation applications, their corresponding services and the window & application manager in an infotainment system.

• Component level: Applications and services are decomposed into components or modules, which typically packaged in libraries.

• Code level: Message sequence charts or structure diagrams. 

In my post, I show context and container diagrams for a harvester terminal. They are a lot more descriptive than my home-grown diagrams from the architecture posts Getting Started and Single vs. Multiple GUI Applications.
Both the context and container diagram give you strong hints how to organise the development teams. Once we have a most likely successful architecture, we apply the inverse Conway manoeuvre to create a team structure mirroring the architecture (see p. 18-21 of the book Team Topologies or my review of the book ).

Reading

Qt Roadmap for 2022

The Qt roadmap reveals some features for Embedded in 2022:

• The list of QBSPs (pre-build for commercial Qt users) is extended by Qt BSPs for NXP i.MX8M Plus, Nvidia Jetson AGX Xavier, STM32MP1, Renesas RZ/G2L and Renesas R-Car E3, H3, M3. The i.MX8M Plus will be my future reference platform.

• The Qt Safe Renderer will finally allow some touch interaction. So far, it only supported showing texts and images.

• Qt will see improved support for Android Automotive.

• Cloud connectivity will be simplified by finishing the Qt HTTP server, better Protocol Buffers and by gRPC integration.

Henrik Kniberg, Anders Ivarsson: Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds (2012)

Spotify's software development organisation knows two core units:

• Squads. Feature teams are called squads. A squad is "designed like a mini startup" with a clear mission. The slogan is: "Think it, build it, ship it, tweak it!" Squads are autonomous and self-organising. They can use Scrum, Kanban, Scrumban or whatever works best for them. Squads work together for a long time. Each squad has a product owner Multiple squads share an agile coach.

• Tribes. A tribe is a group of squads that work in related areas, e.g., the same product line. The squads of a tribe are in the same office - often with open spaces next to each other. Each tribe has a tribe lead. Each tribe holds regular informal gatherings, where members show their work, deliveries and lessons learned.

Naturally, squads have dependencies on other squads. Spotify reviews these dependencies every three months. They classify the dependencies as "No problem", "Slowing", "Blocking" and "Same tribe". Blocking or cross-site dependencies are most problematic. Spotify eliminates these dependencies by "reprioritisation, reorganisation, architectural changes or technical solutions".
As squads work autonomous, they may reinvent the wheel, because they don't know that another squad or tribe has found a problem for their solution already. Spotify ensures communication between squads and tribes by chapters and guilds.

• Chapters. A chapter comprises people who have the similar skills and work in the same competency area. For example, there could be chapters for the GUI, for machine firmware or for cloud services. Whereas squads cut vertically through the software, chapters correspond to horizontal layers. The members of a chapter are from different squads but from the same tribe. Chapters meet regularly "to discuss their area of expertise and their specific challenges".
  Each chapter has a lead who is the classical line manager for the chapter members. The chapter lead is always a member of a squad, "which helps him to stay in touch with reality".

• Guilds. Chapters ensure the communication between the squads of a tribe. Similarly, guilds ensure the communication between members of different tribes. A guild is "community of interest, a group of people that want to share knowledge, tools, code, and practices". Each guild has a guild coordinator.

Spotify has over 100 distinct systems like playlist management, search, payment, iPad player and radio. All systems have a system owner who takes care of architectural issues "like quality, documentation, technical debt, stability, scalability, and release process." System owners are also normal squad members and spend roughly 10% of their time on system stuff.
A chief architect coordinates the "high-level architectural issues that cut across multiple systems". The chief architect recommends solutions. The decision always lies with the squad building the system.

Gregor Hohpe: Would you like architects with your architecture?

Gregor defines four architect personas:

• (1) Benevolent dictator: Architect decides, team executes.

• (2) Primus inter pares: Architect in the team.

• (3) Architecture without architects: Architecture done by team members.

• (4) "Implicit' architecture: The inmates are running the asylum.

When your software resembles a big ball of mud, when decisions are not taken or not followed, when teams don't cooperate, it's time to bring in the benevolent dictator. The emphasis should be on "benevolent". The architect actively searches the feedback from the teams and slowly changes into a primus inter pares (the first among equals).
As Architect (2) is part of the development team, feedback is a lot faster than for architect (1). The "overhead of steering committees and reviews" is gone.
Scenario (2) can turn into scenario (3), where every developer is responsible for architecture. And every developer takes this responsibility seriously to avoid falling into scenario (4). Scenario (4) means that no one is responsible for architecture and that everyone does what they want. It should be avoided by all means. Or, it's back to architect (1), the benevolent dictator, to clean up the mess.

How to move the default /var/lib/docker to another directory for Docker on Linux

I use Docker containers regularly to build embedded Linux systems with Yocto (see my posts Setting Up Yocto Projects with kas, Building a Linux Image with Yocto and Building a Qt SDK with Yocto). The Docker image easily have a size of 1 GB and more. And I have many Docker images. My root partition filled up quickly. I had to purge images several times to avoid overflowing.
Last week, the disk was nearly full again. I decided to move the Docker images from /var/lib/docker to a custom location on a 12 TB RAID. This should keep me out of trouble for some time. The fool-proof step-by-step description from the title link was exactly what I needed. Just one remark: The command to start dockerd should use the documented option --data-dir instead of the undocumented option -g.