A holistic approach to software efficiency

Avoid waste. Minimise detours. Reduce complexity. The topic of efficiency is omnipresent in connection with software. It fills entire books, collections of essays and research volumes. Software efficiency is understood here primarily in the IT sense. This means that the efficiency of algorithms takes centre stage.¹

Efficiency in the general sense means using the available resources as sparingly as possible.

In short: a development process is efficient if the effort required is in an economic relationship to the achievement of the project goals.

In economic terms: How can I achieve the best result with the least amount of money?

Software efficiency is a bit like the legendary pot of gold at the end of the rainbow: everyone wants to get there, but nobody knows the way. Why is that? Mainly because software efficiency is often given far too little thought. A holistic approach is needed to become fit for the future. This is what this can look like and why it is necessary.

What is software efficiency?

Anyone searching for software efficiency will quickly come across definitions from complexity theory.² This is a branch of theoretical computer science and deals with determining the resources required to solve a problem. Within computer science, the topic of efficiency usually refers to relatively easily quantifiable elements such as runtime or memory efficiency. In other words, questions such as: Does programme A run faster than programme B and which one requires less memory? This tradition explains why only the development area is usually considered when it comes to efficiency. But: This is too short-sighted.

A lot can go wrong along the way and also afterwards, for example in production and logistics. That’s why the entire product development process should be scrutinised! Software efficiency can be described as the undertaking of creating high-quality software products that are durable and can be further developed and operated sustainably – in less time and at lower costs. Many factors play a role here. The development of functionalities is only one aspect of this.

Software efficiency as an important but little recognised topic

Processes and systems are like the body. You only realise that something is wrong when it starts to ache and hurt. By then, however, it is often too late – the nose sniffles, the code throws itself on the floor and makes mimimi. But: The error that occurs now is often the result of a previously made wrong decision. So the wrong turn was usually made beforehand. This can affect very different elements. Well-known problems are, for example, when

• responsibilities are missing and competences are unclear.
• employees have to iron out problems that were caused elsewhere.
• people are reluctant to buy in expertise and instead prefer to burden existing developers with the additional and unrelated workload.

The list of pitfalls is long. There are a whole series of indicators that clearly show that inefficient action is being taken.

Three examples of red flags:

1. Your teams have an enormous backlog and features are only completed slowly or do not add the desired value because teams from different development areas are blocking each other, e.g. due to a lack of transparency.
2. Decisions are delayed or the transfer of knowledge does not work because highly specialised roles, niche knowledge and gatekeepers prevail in the company instead of standardisation.
3. Releases take (too) much time and/or code can no longer be maintained or can only be maintained with considerable additional effort and time because the system complexity has become too great and confusing.

These cases can only be solved if the product development process is understood and treated as a complex whole. Software efficiency is key to generating long-lasting, sustainable and high-quality products and processes. However, it is only sustainable if it is not thought of in terms of individual parts. This is because it is not identical to efficient algorithms. This means that anyone who only invests their resources in these or in individual sub-areas will sooner or later run into problems. Efficiency must be understood holistically, in a development process that encompasses man and machine.

Why software efficiency should be thought of holistically

So: efficiency in the context of software is often understood in an abbreviated way. Usually only in relation to the pure development of the software and its features. This is problematic. After all, disruptive factors can occur anywhere in the process. For example, through self-created bottlenecks:

• When the employee who wrote the code for the company’s own programme on their own initiative (and just as unconventionally) leaves and it remains a mystery to everyone else in the company.
• Or when employees want to use a particularly unusual or trendy programming language – but the costs and time required for familiarisation are not included in the efficiency calculation.
• Or when the development manager is both requirements manager and tester at the same time, aka a missing checks and balances system.

There are predetermined breaking points for inefficiency everywhere. At both process and human level. Understanding software efficiency only as the sum of short-term, reactive hotfixes that try to iron out errors on the go falls short. Software efficiency should therefore be thought of holistically. This means that the development process should be considered in its multidimensionality.

What areas does holistic software efficiency cover?

The holistic approach essentially covers four areas:

• Software architecture and coding,
• production,
• quality assurance and
• the people and teams involved.

These four basic areas can and should be supplemented by other aspects such as requirements management, organisation or processes if demanded.

The important thing is that all parts should be given appropriate consideration and resources. And similar to Gestalt theory, the whole is more than the sum of its parts. The individual elements should not be considered in isolation, but always in combination. This is because the interactions between the areas can be extreme. For example, a young start-up in which only one of the four founders works full-time and thus becomes the head of everything, which has a negative impact on all processes and the end product. Or the traditional company that has to deliver several hotfixes with every release due to errors that build up over long periods of time, making it practically unable to work.

Another key aspect of the holistic approach is to use standardisation wherever possible. On the one hand, this ensures that you can act and produce faster. On the other hand, it is simply more cost-effective, for example if external expertise has to be purchased.

Conclusion

Focusing on and optimising only one or a few elements of the product development process automatically creates predetermined breaking points. Right up to catastrophic results. Some software is no longer maintainable because it has not been sufficiently tested in its entirety. Or, for example, problems occur in the production process because too little testing was carried out during development and these errors now have to be rectified in the production system with far more effort, time and money.

The holistic approach of software efficiency avoids these potential predetermined breaking points. This is because it considers and optimises the big picture: the various phases and areas of software development as well as the people involved in the process itself. This results in a more sustainable approach, more durable products and systems, more maintainable and resilient code is created and companies can (once again) go into production faster with executable systems and products. And all this without burning out the people involved in the process. So that your code no longer has to throw itself on the floor and make mimimi. And neither do your employees.

Notes (partly in German):

This is a joint contribution by Dr Vera Baum and Tobias Varlemann from QualityMinds.

Do you also want to develop future-proof software efficiently? QualityMinds offers an interesting workshop in German: Sustainable software development from design to operation. Definitely an interesting offer.

[1] Jochen Ziegenbalg, Oliver Ziegenbalg & Bernd Ziegenbalg: Effizienz von Algorithmen, https://link.springer.com/chapter/10.1007/978-3-658-12363-5_5
[2] Lexicon of mathematics: Komplexitaetstheorie
[3] Ingo Wegener: Komplexitaetstheorie – Grenzen der Effizienz von Algorithmen, https://link.springer.com/book/10.1007/978-3-642-55548-0

If you like the article or want to discuss it, please share it in your network.

You can find more articles by QualityMinds on the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.