“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.
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.
“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.
“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.
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?