Every piece of software still in use is going to expand tremendously, that’s a given. What can be done to contain the associated cost increases?
Software development is similar to hardware development, yet also very different. Many companies that were hardware oriented in the past struggle to make the transition towards being a software company that also develops a bit of hardware. Software is like a gas: as there’s always new functionality to realize, software size will grow to the extent of the container – and the cloud is a seriously big container.
Keeping existing systems up-to-date usually means a 10-30 percent increase in code size per year. This empirical range is found in well-known systems such as Linux, Windows and Photoshop but also in automotive entertainment systems. The code increase is mainly the result of adding additional functionality and features, while the main aim of the system doesn’t change. When developing completely new functionality, such as control software for autonomous electrical driving, your codebase can easily grow 60-70 percent per year.
What can be done to contain the associated cost increase? In software development, there’s a tendency to look mainly at the efficiency of an individual developer or development team. While that makes a lot of sense, I believe there’s a lot to gain by looking at optimizing software development at a higher level.
First, separating concerns in your architecture is key. Choose the right modules and remember there’s no such thing as being too scalable, too maintainable or too extendable – there’s a trade-off with initial cost and time to market though.
Second, do not develop anything in-house when there’s a good alternative already out there. This may seem obvious, but I often wonder if we commit to it. We’re quick to find reasons why we can do it better ourselves and often don’t spend enough time to really investigate what’s on the market already, both commercially and in open-source communities. In the same category: keep investing in the latest and greatest in terms of off-the-shelf tooling and development environments.
Third, make a clear distinction in your software layers. The core of commercial systems is relatively small in code size but essential to the performance. Whatever is close to the heart of your system performance or has major safety or security implications when breached should explicitly be protected against unintended changes in behavior.
Fourth, automate everything you can as long as the return on investment in the long haul is positive. Software developers are your most important asset, so reducing their time spent on repetitive tasks increases the efficiency of your whole development process.
Fifth, follow the trend of low-code and no-code software assemblers to speed up delivery of new features. If sufficient building blocks and facilities have been created, users should be able to assemble them like Lego to create new functionality – low or no coding skills required. Addition of a new user screen, inclusion of parameters to adjust hardware settings, visualization of all kinds of diagnostics and performance parameters – just create the possibility for users to do this themselves. A necessary prerequisite here is of course the previous point: from creating software code to performing the necessary tests, it all has to be automated if you want to benefit from the low/no-code assembler trend.
Last but not least, be agile and move on when something isn’t working. Another obvious one, but we keep getting stuck in this psychological trap. Consider the money and effort you’ve spent already as water under the bridge. Look at what you still need to spend to make it to the finish line. Stop using a process, service or tool that keeps giving problems; stop developing when it’s not the right path anymore.
If it’s effective and efficient development teams you want, you might want to take these higher-level optimizations to heart.