Abstract:
Productivity Growth in Software Production through Software Analytics
The New Economy of the early 2000s heralded its arrival with a crack of thunder – just think of the fintechs, whose technology-driven development set out to turn the financial sector upside down. Largely unnoticed, this revolution is now also reaching traditional industries. Even Volkswagen, for example, has announced that it will define its brand through software in the future and is bundling the expertise of more than 5,000 digital experts in the new "Car.Software" unit. But no matter where you look: Software development is still a long way from the highly optimized production processes of industry – even though the biggest cost traps have long been known.
"Ideally, the internal or external client of software development wants to see every euro of the invested budget translated into a full 100 cents of software innovation," says Marc Hildebrandt, CEO and founder of technology incubator German Deep Tech, which transforms academic excellence into industrially usable software solutions. "However, as teams get bigger and projects get more complex, you inevitably move further and further away from that goal as more budget falls by the wayside."
Cost Trap:
Procrastinating troubleshooting
Even if it sounds trivial: bug fixing accounts for the largest productivity trap, and on top of that, an unpredictable share of developers' working time. This doesn't just mean routine testing of the software as part of the release cycle. What's really problematic are the bugs that make it to the end users. The Six Sigma management system for process improvement knows the rule of ten for this: the cost of an undetected bug increases by a factor of 10 from one stage of value creation to the next. The earlier a bug is discovered and eliminated, the more cost-effective this is for the organization.
Above all, defects found late in the delivered code are frustrating for developers because they often have to be fixed with a lot of effort and in a hurry, while the actual tasks are put on the back burner. Sustaining success and motivation in the team over the long term while optimizing defect resolution can be a major challenge to work organization – whether individual developers are responsible or the burden is shared equally. "At the end of the day, the team has to decide what feels better: alternating between volunteers who are intensively bug-fixing and are available for requests, or parallel work, which is distracting in any case and causes the team to lose focus," summarizes Dr. Markus Friedrich, Special Development –Vehicle Networking Architecture at the BMW Group in the XING forum "SCRUM".
Cost Trap:
Incurring technical debt
When software developers have to work under pressure of time, they tend to deviate from the agreements actually made and to program imprecisely. This can make sense in individual cases in order to meet release deadlines or to carry out rapid bug fixing. Such places in the source code are also called technical debt. The interest is paid by those developers who later have to continue working with the code, for example to extend the code. They need more time to get up to speed, make progress more slowly, and are more likely to make mistakes.
As sensible as taking on technical debt may be in justified individual cases – the decision against a clean solution becomes easier each time. This effect is known from social psychology as the broken windows theory: It is easier to break another window on a building with numerous windows that have already been destroyed than on an intact building. If the omission or shortening of process steps becomes the norm in the development team, over time a patchwork of non-conforming code is created that is almost impossible to maintain.
Figure 1: Visualization of a complex code system with Software Analytics.
Cost Trap:
Eliminating technical debt
Technical debt is inherited baggage that can hinder the development process to such an extent that it comes to a virtual standstill. At the very latest, when the client gets the impression that the team is only concerned with itself, there is no alternative to operational intervention in the code. This can be performed minimally invasively in the form of refactoring – whenever affected code needs to be touched, the legacy is removed at the same time - or it can be carried out jointly by the team as a large-scale redesign of the code in one fell swoop.
"Whether in-house or externally, whether by hand or with tool support – the elimination of legacy issues can be optimized, but time and money must always be invested, which are then no longer available for the actual development tasks," says Günter Hofmann, Managing Director of the application modernization service provider fecher. Nevertheless, he believes it is worthwhile to make this effort sooner rather than later: "The biggest surprise for the development teams is always to see how much easier further development now is once a modernization project has been completed."
Figure 2: The biggest cost traps in software development.
Cost Trap:
Allowing knowledge monopolies
In a complex software project with hundreds of thousands of lines, not every team member can know their way around the remote corners of the code base. However, it always becomes dangerous when knowledge monopolies arise and success depends on a mere few experts. In risk management, such monopolies can be described by the "bus factor": How many people would seriously jeopardize the project "if they were run over by a bus". This striking description naturally includes more harmless reasons for failure such as illness or leaving the company.
"Just imagine that a key member of the project staff unexpectedly drops out for two or three weeks," says Dr. Martin Kuhlmann, Senior Solution Architect at Omada. This could cause the project to come to a standstill, as other team members would require a long time to be trained before starting with the unfamiliar code. "Dependence on individual members is always a great danger for the team," Kuhlmann emphasizes. One way to counteract this is with agile process models that promote regular exchange and distribute responsibility for the code among all developers.
Software analytics shows approaches. Relevant estimates put the losses due to cost traps such as those mentioned above at over 50 percent even in medium-sized software development projects. In large, complex projects, they can easily add up to 80 or 90 percent. "If only 20 percent of the resources used in a project are actually used for the purpose for which they were intended, people in the business world would act quickly," says Hildebrandt, a deep-tech entrepreneur. "How can we find that acceptable in our highly technical software world, of all places?"
In fact, even in Fortune 500 companies, the development of complex software systems has so far been managed more as an art form than as an engineering science. The process breaks down into different areas of responsibility, each of which is dominated by its own language and viewpoint and uses isolated software tools. Agile methods can alleviate the silo problem somewhat with their organizational forms, but they also do nothing to change the fact that the process spans across the fields of expertise. Thus, a constant translation between the artifacts and language worlds must take place and the traceability of the process remains purely wishful thinking, especially in the enterprise context, when several teams develop together on a large system. If those responsible in management want to gain an overview, they have to obtain information from the respective technical experts and, in the absence of a common data basis and language with the technical experts, ultimately have to rely on their gut feeling.
Just as in the business world, Big Data and Business Intelligence (BI) have led to reliable decision-making principles based on hard facts being available to management at all times, the relatively new discipline of "software analytics" aims to achieve the same with the process of software development. "In repositories and all the other tools, we have excellent, precise data about all the essential aspects of software development," explains Prof. Jürgen Döllner of the Hasso Plattner Institute for Digital Engineering (HPI) in Potsdam. "Until now, there was simply no recogn that you can generate valuable knowledge from this data."
At the end of the day, the client gets more innovation for his invested budget
Implement targeted improvements. This knowledge only emerges when you look at the complex process of software development from requirements management through coding and testing to release management. "Only those who know where the losses occur in the overall process can take meaningful countermeasures," explains Managing Director Dr. Johannes Bohnet of Seerene. For this purpose, the HPI spin-off offers business dashboards in its Seerene Analytics platform, on which the individual KPI key figures can be tracked in real time. In the event of deviations from the target value, all those involved, from the company leadership to the technical experts, can then drill down to the exact cause.
For example, if the team spends too much time troubleshooting, it is possible to analyze exactly where in the code base the problems arise and where the developers actually spend their time fixing bugs. "This kind of knowledge is extremely valuable because it has consequences: Like a surgeon, I can now fix the handful of places in the code that are really the issue," Bohnet said. The time saved is then available for additional productive work. "At the end of the day, the client gets more innovation for his invested budget," the software analytics expert is pleased to say. "In almost every software project, an ad hoc increase in productivity of over 30 percent can be achieved in this way."
