CMake line by line - Building and Android APK with Qt5

If you build GUI applications with C++ and Qt, chances are that you have to create a mobile version of it. While the discussion, if Qt and C++ or the native Android SDK is the right technology to use is certainly worth a tought, there are situations where it makes sense to stick with Qt and C++. This article illustrates line by line how to build a C++/Qt application for android with CMake and how to pack it into an android APK.

“We really struggle to bring engineering topics into the roadmap! When do we finally get the time to improve our code quality?” Many software development teams gripe when it comes to getting engineering topics into a product roadmap. For many, improving the lesser visible aspects of software quality comes second putting more features into a product. Nevertheless, creating quality software is a necessity if products are expected to perform on the market and be developed for a long time. The ISO 25010 model for software quality lays a good foundation to discuss the quality topic with the relevant stakeholders and with a few easy-to-learn tools putting features that improve the quality into a backlog becomes much easier.

When Packt Publishing approached me in august 2021 with the idea of writing a book about CMake, I immediately was all for it. Ten months later I am mightily proud that “CMake Best Practices” finally hit the shelves. As this would be my first book, I had no idea what I was getting into when I signed the contract with Packt. The months of writing the book were among the most exhausting ones in my whole career and they were an emotional rollercoaster, but I also count them as one of my most valuable experiences. And finally seeing the book getting the first customer reviews really rocks. So how is it to write a book for Packt as a first-time author? In this article, I try to give a few insights into my writing journey.

The Mountain Mind - Mountain climbing and software development are the same

When planning a climbing trip the goal of reaching the summit is often known, but how tough it really is to get up there is something that can only be judged in detail once the climbing starts. Some mountains look almost impossible to climb and yet they are relatively easy to summit, while others look comparatively tame but require quite some effort to get up to. Starting a software project is often very similar. While there might be a general idea of what problem or business case the software should solve, it is often unclear what is needed to get there. Some things might turn out much harder than anticipated, while others will be solved surprisingly quick.

Reproducible build environments for C++ using docker and vscode

“But it compiles on MY machine!” Is one of the phrases that every C++ coder hates. Even with CMake building a C++ app is often hard, because of missing system dependencies, or people have different libraries installed or are just building with another flavor of make or ninja. But thanks to the remote container extension of visual studio code this has gotten much easier.

Agile is all fun and games once you’re up and running, but how does one start developing a software product in an agile way? There is a lot of information out there about how to run an agile team - Be it with scrum, kanban, or any other flavor of a variety of agile processes. But when it comes to how to get started, most advice is “just get going”. So how does this “just get going” look like?

Project based “Design first and build it once” approaches are a waste when creating software. Software engineering benefits hugely from an agile approach to product development - not just because software lets us tackle more complex problems, but also because of the different constraints that software development faces compared to other engineering disciplines. Software is wonderfully volatile and easy to change compared to other engineering disciplines, so a different way of building products is necessary.

Frequent vertical integration for the win

“The software is almost done, we just need to integrate it on the device.” Is one of the biggest self-deceptions in embedded software development. What often follows are failed deadlines and weeks or months of everybody taking shortcuts and hacks to finally ship that device. And often enough, what could have been an awesome product severely lacks quality in the end. Early and frequent vertical integration is THE way out of this deadlock and often a huge game-changer towards better products and agility.

Having a high-quality backlog is a cornerstone of lean-agile development. The backlog is a central part of agile software development. Whether you’re doing Scrum, Kanban, or any of the scaled agile approaches, virtually all methodologies have a backlog as the central artifact of storing upcoming and current work. Because of its central role, handling the backlog well and keeping it lean is a necessity to unlock the possibilities of agile development.

Agile software development in a regulatory environment

I would like to do agile software development for my medical devices, but the #$%! regulations make it impossible! This response is common when asking people from med-tech or similarly regulated industries about agile software development. Contrary to this popular belief, developing regulated software in an agile way is not as hard as one might think. Yes, going agile will not lessen the additional overhead required to pass a regulatory audit. But by focusing on creating artifacts and features which bring value to the products first, the result will be better products.

CMake is awesome, but it can be hard to figure out. Over the last few years, CMake has become one of the most popular ways to build C++ applications and libraries. Unfortunately, you might be stuck with an existing piece of software that is built entirely differently - be it makefiles, gradle, Qmake or even a completely custom-built way to compile software - you name it. So what if you want to move your codebase to CMake without rewriting the way all these old dependencies are built?

Ditch the estimates and start forecasting

“NoEstimates cannot work because people want to plan ahead.” Sounds familiar? Actually NoEstimates means does not mean the absence of any forecasting and planning ahead. Quite the contrary. By tracking the throughput of a team and having a lean development process planning can actually become more reliable, despite not estimating a single story.

99.9% of software bugs are caused by programmer mistakes. Testing and code reviews help, but are not enough. If bad code could be caught even earlier, that would be so much nicer. With Design by contract we software engineers get a tool that does exactly that. Design by Contract not just makes code more correct, it also makes it more readable and much more robust against regression bugs.

Breaking down stories in small, manageable chunks is an essential skill when maintaining a good backlog. Sounds good, but how does one actually do the slicing? Splitting backlog items is not magic, but a skill that can be learned. All it needs is a bit of thinking and a few techniques to get going.

How does remote teamwork actually work? Working together remotely has its challenges, but they are not as big as one might think from the cozy office of a co-located team. While the communication bandwidth of physical face-to-face communication still beats everything else, but modern technology and a few rules for online behavior can make up for a lot.

Change is everywhere in modern organizations. Those organizations that find it easy to change succeed, the others suffer. Life in modern companies is signified by fast and frequent changes. Be it agile transformations, digitalization, new tools, new technology, new methods, new processes (and much more) - there are are many powerful drivers for change in a modern VUCA-World The stories of painful and failed change are abundant, yet there are organizations that successfully change frequently without all the pain. What makes their changes much more likely to succeed? And how make they change appear easy? Together with colleagues at bbv Software Services we dove into the topic and we came up with seven major factors that contribute to successful and lightweight change.

A good part of leadership is to bring inspiration and purpose to people in order to motivate them do get things done. In modern companies job no longer falls to a single boss-leader, but situational, decentralized leadership is the way to go. In essence “whoever knows best” leads the way. In the book Start with Why and a TED talk, the author Simon Sinek describes what he calls the “golden circle” as a model to create purpose and inspiration. In the tiniest nutshell the method consists of three concentric rings, “Why” (innermost), “How” and “What” (outermost) and these questions get answered inside out.

“We only learn through failure. This quote attributed to the legendary alpinist Reinhold Messner holds a lot of truth in it. Modern organizations like to talk about good failure culture, but is failure in every circumstance a good thing? Probably not. As a software engineer and climber I saw a few fails with sometimes quite drastic consequences. Failure is never the goal but sometimes unavoidable, so how can we as individuals, teams and companies benefit from it?

What is your organizations currency of getting things done? When trying to getting things outside daily business done, every organization reacts to different kind of arguments and incentives. “Paying” in the right kind of arguments is often the key to get ones concerns put into action.

CMake can be hard to figure out. I love CMake, but unfortunately, its documentation is more focused on completeness than on providing hands-on-examples. Since I found it hard to find a comprehensive example of how a header-only library can be set up, I decided to provide an example of a CMakeLists.txt file for such a library here and analyze it line by line. The example is taken from SI, a header-only library that provides strongly typed physical units. In order to keep the CMake file as small as possible, a few possible optimizations are omitted. Notably, I stripped any information relating to testing out of the project.

Are modern organizations ready to pay the price for increased demand for their leaders? Countless companies and organizations are currently changing how they work internally. Some experience a growth spurt in the wake of digitalization, others want to be more flexible in reacting to change. And a lot of these organizations struggle with these transformations. They got the agile framework of their choosing in place, they got the teams set up and maybe they even streamlined their portfolio and technological infrastructure. At first, everything looks good, but after a while, all the shiny new things start to lose their gleam and things become tedious again. Decisions take ages to be put into action and once a course is set, people find it hard to deviate from it. All the fluffy stuff like empowerment of the teams and people somehow does not seem to happen. These symptoms might hint that an organization is suffering from “leadership debt”.

Scrum is hard and tedious! It’s like groundhog day for software projects! Ever noticed that scrum does the same thing over and over again? Plannings, retrospectives, dailies, backlog refinements… Each sprint we do the same thing! Especially for long running projects this becomes boring. Programmers follow the Don’t repeat yourself paradigm, so why we do differently in processes? There has to be room to optimize, right? There is a solution to it: Scaled Single Sprint Scrum - It’s like scrum but totally different!

SAFe is the worst implementation of “corporate agile” that is out there! Over the last few months I heard this sentence or a variety of it a few times. There is some truth to it, but it is not the whole truth. The SAFe-framework is far away from what I imagine when thinking “agile”, but there are some aspects which are pretty neat. Despite all the critics it is a very popular framework that is implemented in a lot of bigger companies. So there has to be something good in it, doesn’t it? Let’s have a more differentiated look at it!

A practical guide to tangible product visions

A good product vision is the cornerstone for being successful at delivering software products¹. Having a product vision that is tangible and accepted by your developers is one of the most important things to have, if teams are supposed to work in an empowered and self-organized way. A vision is not just a good advertising tool, but it is the foundation to creating a purpose for everyone’s alignment towards what the product shall be. It is a common pattern, that companies that struggle with creating good product or company visions, find it very hard to create alignment and motivation in those employees who are building and delivering their products.

Actually this is true for any product in development, not just software. ↩

Most hobby projects die at the idea stage - Mine do not. A while ago I decided to revive an old idea of mine to implement the International System of Units as a strongly typed C++ library. In order to try to bring this project forward I tried an experiment: I would make at least one commit each workday for a month. A month later I am somewhat proud to say, that I kept this promise to myself with only one “comittless” day. But how does my pet project look now?

How good are your decisions? - Every day we decide a lot of things small and big. At work or any professional setting we often have clear deciders. This can be a senior subject matter expert, the traditional “boss” or some collaborative process in an empowered team - it does not really matter. Contrary to our private live, in business we often have to make decisions more explicit and documented, for instance in the form of meeting minutes. Some people are good at deciding, others find it very hard.

What secret agents need to work successfully

The core capital of modern companies are their employees. This fundamental truth is even more important for companies operating in areas that require highly trained and motivated people with a high degree of initiative. It is not just software companies that fit perfectly into that scheme, but almost any engineering-driven company and many, many companies outside classical STEM fields. After all as Humphrey Watts said: “Every business is a software business”. In the article “The James Bond Package” I wrote how having someone with the skills and mentality of James Bond in your company helps a lot when solving complex problems is daily business. However getting James Bond to work for you and then be able to unlock his full potential needs a company culture that fits the modus operandi of a secret agent.

Due to his combination of skills, motivation and initiative James Bond is the perfect agile problem solver. Agile working requires empowerment of teams and individuals, self-organizing and a different mentality than classical command-and-control structures. This is not just the case for the leaders but also for the people actually solving the problems and delivering the products. To perform in such an environment it helps if each and everyone of us shares a bit of what I like to call the “James Bond Package”.

“It is really demotivating, nothing gets done here.” A complaint I heard a few times in various settings. Sometimes just as a exclamation to vent steam, sometimes with a sigh and an edge of desperation to it. Surprisingly most of the time I hear this, it is from people that I esteem as far from lazy and quite capable of actually doing and completing things. But lack of motivation can strike the best of us.

How to iterate fast when developing software and hardware together

Iterate fast and often to make better products. This rings true not just when creating software but also when developing it close to or together with hardware. IoT and fully automated Industry 4.0 are currently big topics in the industry, which promotes integrated development between hardware and software even more. Unfortunately, the reality is often that software- and hardware-engineers fail to work effectively together and because of this struggle with creating awesome products.

Unpacking a fixed-size container in C++ can be tedious, and require you to fiddle around with std::get or std::tie. But not anymore, thanks to the new structured bindings introduced in C++17. Unpacking anything with a fixed size into named variables never has been easier.

Agile is successful and we know it. For years we scrum masters, agile coaches and change champions advertised and trained developers in the agile principles and the many frameworks and ideas out there. We have seen teams and individuals grow and become self-organized and empowered. It was fun but tough work. We grass-rooted ideas with the developers and helped people changing their minds about “how we work”. And it was frustrating when we hit the hard wall of culture-shifting whole organizations instead of just teams. Our teams worked well but somehow the movers and shakers of the companies needed a lot more and a different kind of attention to bring them along. Suddenly the ideas and principles we instilled so successfully into cross-functional teams of developers, testers and engineers were under harsh critique. Somehow there always seemed a someone up a higher level that did not agree with what we tried to achieve. Countless stories of trying to put scrum into action on a contract that is essentially waterfall are a strong indicator to that.

Better estimates by using applied linguistics

Planning poker, magic estimation, T-shirt-size estimation and even the famed #NoEstiamtes are too inaccurate - But there is a way to estimate to up to 50% more accurately by using a simple formula based on empirical measures and applied linguistics. Notice how developers use the same qualifiers for estimating workload over and over again? “It is just a minor bugfix”, “This is a huge, complex task”, “There is absolutely no way I can put an estimate on this one”. Heard this sentences or variations of it in the past? Your best estimations are lying in front of you in plain sight.

Do not leave your innovation to the engineers

We need to be innovative! - I heard this statement or a variation of it a few times over my past in working as a software engineer. We engineers love this, as we get more time to tinker with anything we find interesting - Which is a lot. The result are often better tools or tool-chains to make our life as developers easier, but very rarely the output of such initiatives improves something tangible for the users of the product we are working on. Why? Because on these innovation days we are usually stuck together with other engineers which means that we mainly discuss engineering problems.

Good code is self-documenting - We coders love this sentence and with the standard attributes available since C++11 we are one step closer to this utopia.

C++ is hard! Luckily the new standards brought some features and tools to make writing C++ easier. Selection statements with initializers are one of these small-but-nice features that make our coding-life easier.

We should stop calling it agile and start calling it modern company culture. In the past fifteen years the word ‘agile’ has become widely popular in software development and other technology affine areas of business, but still people find it hard to find a consensus on what ‘agile’ means for them or their company. There seems to be an agreement that agile development contains such processes as scrum, kanban, xp or on a bigger scale SAFe, Less or any of the other frameworks out there. But an often heard complaint by people involved in software development is, that they are never “100% agile”. Or that they do scrum but find it hard to get that elusive culture shift happening in their companies.

C++17 - is officially out! So what can we as coders expect from it? With C++17 the standard-comitee brought further modernisation into the language. C++17 brings a set of new features which enhances convenience for the coder and makes writing portable code easier.

Agile is shortsighted! In scrum you are only interested in what’s going on in the next sprint! Kanban focusses only on what’s next! Long term planning is not agile! Sounds familiar? The gap between short term (sprint-)planning and long term roadmaps is an often discussed focus point in the world of agile and an often cited reason why “our company cannot do agile”. And it is true. A lot of litarature advertises mainly the fast reaction time and short iteration cycles that agile methods give us, especially if applied to software development. But it is also true, that a lot of businesses are operating on longer cycles than single sprints. Yearly budget allocations, fixed cost projects and hard deadlines are real and existing challenges in the industry. Leaving aside if this is how it should be or not, those practices are still alive and kicking in a lot of industrial sectors such as the medical or machine industry.

Five and a half steps to efficient meetings

Meetings are boring, overcrowded, take up much of your valuable time and don’t produce the desired results. Or they can be interactive, efficient, goal-driven, interesting and sometimes even fun. So how to go about planning and running successful meetings? Five and a half Steps to successful meetings

The Seven Must Reads For The Aspiring Agilist

Over the course of the last few years I read a lot of books about agile principles and teamwork and there are some that stood out to me as particularly worth to read. Most of the books are rather about agile teamwork in general than any particular methodology such as scrum or kanban. These books are also starting point on the way to knowing and doing agile, so the list is obviously by no means complete.

Get Professional - A professional skillset for software developers

Everybody is a great coder! It’s now over fifteen years since I first got money for a program that I wrote, and since over ten years I consider myself a professional software engineer. When I started out programming I was convinced that raw coding ability and deep, innate technical knowledge of a few programming languages would be all it would take to make it in the industry. But over the years I learned that there is more to being a professional programmer than hacking together complex code. Having worked both in academics and industry, this often became most apparent to me when working with newbies fresh out of college. Often they are great programmers, but lack some of the surrounding skills to make them look professional to me. So what distinguishes the common coder and/or hobbyist from the pros? Before I forget: This article is written on a purely subjective basis of my personal experiences, feel free to tell me that I’m wrong