Software Excellence: 7 Dimensions of Successful Software Development

JK: Hello and welcome to another Deep Dive podcast by Digital Kompakt. My name is Joel Kaczmarek and today we talk about a very, very interesting topic, namely software development and later on also about the necessity of software analytics. Software is an omnipresent topic and therefore mission critical. That is why it is a matter of the heart for me to talk about it, especially in times of Corona where digitalization is basically forced upon us. That means that you will get a better understanding from today's episode on what exactly software development means or, rather, what it comes down to, which different kinds of software there actually are, why software is never finished and what is really fundamentally important in order to reach excellence in software development as well as many, many more things. This much I can disclose. Today I have a ten-page script for once. I actually never had that before that my conversational partner comes up with so much content beforehand so that we have such a huge foundation. So therefore, I am even more delighted. I used to work at a company that has also worked with Johannes Bohnet's company, who we will talk to shortly. So, we were basically colleagues. You can affectionately call him Hans if you work together with him. And he has a very, very interesting company. He founded it himself and he's Co-CEO there. It is actually concerned with the field of software analytics which he invested many years of research into at university. And this beautiful company is called Seerene. Dear Hans, nice of you to join us. Welcome. 

JB: Yes, hello Joel. Thank you for having me. 

JK: Tell me a little bit about Seerene before we start so that you can give us a feeling of what your background is. Maybe tell us one or two sentences about yourself. 

JB: Yes, so you already said it. Seerene came into existence through research that we did at university. I wrote my doctoral thesis there in the field of software engineering. And parallel to research at university I had worked at an IT company so that I always got wind of the terrible things that were happening in the real world, how hard it is to actually manage software development, to get a handle on it and to do it well. I saw that with big companies, with small ones, throughout all lines of business. There I saw the challenge. And then we thought at university why we didn't just use the method of analytics, of machine learning, back then it used to be called big data for the most complicated thing ever built by humans, namely software. And that was the starting point for the research. And relatively early on we saw that demand for it was so immense on the market because software is underneath everything. And we wouldn't have been smart if we hadn't commercialized it or turned it into a product. 

2. How software errors influence the world 

JK: So, I can assure the sympathetic listener that Hans has, if I am not gravely mistaken, successfully finished his degree with summa cum laude. He is a 150 percent man. So I know that everything that we did together at work back then was somehow always at the very least 50 percent above the top level. So, he has high aspirations and most notably he has a whole lot of practical experience. This means, dear listeners, listen closely. I believe you have struck gold knowledge-wise with Hans when it comes to the topic of software. That being said, you hear a whole lot in the media or read about the fact that somehow there are very often mishaps in the economy that have to do with software in one way or another. Maybe we use that as a broad entry point because you also just said that software is omnipresent. How does that happen? 

JB: It really is the case. So, when you look at the media, in every newspaper issue there is at least one of these reports that somewhere things went south again because of software. If you analyze that a bit, you see that there is no hotspot and the focus is not on one specific industry. Rather, it's the case throughout all industrial branches, auto manufacturers, banks, insurance, supermarket chains, everywhere. Volvo recently had to call back, believe it or not, 750,000 cars because they had a software error in the brakes system, so it was critical. Since March 2019, all Boeing 747 Max airplanes are on the ground after one of them crashed. Deutsche Bank comes up time and again. They basically fight constantly against errors in their central payment system. You can see there that software is basically the backbone in the foundation that the business is then built upon. If the software does not function, the business crashes. 

JK: But is software then essentially the problem or can you maybe tier that to some extent? Are there maybe kinds of software of which some work really, really well and others don't? 

JB: So, if you really analyze it and you want to improve it, you look more closely, then you see that there are actually two kinds of software. One kind is unproblematic. Those are the so-called off the shelve software products, namely software products that I can basically take off the shelve at the software supermarket and that I can then use, Microsoft Office for example. Sure, if errors occur in those, then that would have massive economic consequences because it is of course being used throughout all branches. Luckily you hear about that kind of disaster quite rarely. Apart from this easy to use software there are also challenging software systems. And those are the so-called in-house developments, custom-made software systems that are being built specifically for a company and that are tailor-made. You can imagine it vividly that those software backbones that I just talked about are down in the foundation and they carry the business structure on top. And some of these software backbones are off the shelve. They are robust, stable, I buy them, and I just put them there. And the other columns are formed in a special way and especially in such a way that they fit the specifics of the business structure above. Why is that? Because these software systems are extremely important for the company because they allow the company to gain a competitive advantage over the competitors. So, everyone can have off the shelve systems. But to have custom-made software columns underneath, that is the difference. The difference is then, for example, that I, as a company, can conduct my business processes much, much more efficiently than my challengers or that I can offer unique products or services to my customers with this software column in the substructure. And this way I can get a distinction from my competitors. Maybe I will give you a few examples so that it doesn't stay so abstract. The Deutsche Börse AG has a custom-made software system for high frequency trading in the substructure. Spotify has a custom-made software for the music recommendation engine. Metro, the wholesale company, has a custom-made system for their purchasing and supply chain backends. 

JK: Do I, as a company, then have to think about keeping the number of in-house developments as small as possible? So would you then consequently say when there is off the shelve that is very well tested, has a long history, where you can be sure that it functions well, that you should rather see to it that you do as much as possible off the shelve and as little as possible in-house? 

JB: Definitely. So that would actually be my advice for every CIO, chief information officer, who is usually in charge of these things. If possible, take off the shelve. The in-house developments are basically very, very challenging. And if I manage to use a standard system that I can simply take and that has professional software companies in charge instead of a self-made system, then that is definitely an advantage. But especially in times of digitalization I have to try and be better than my competitors and to prevail against the competition. That means that I will always have a software column in my foundation that I want to use as an in-house development. This assessment between what should be off the shelve and what should be in-house should work in a way that only find in-house developments where you really want innovation and the distinction from the competition. 

3. Why software is never finished 

JK: Okay, for my core net product it would be important then to have something that I have developed in-house so that I can build up these barriers of entry as you put it so nicely in the startup sector. But then every company would just have to begin at the point, so to speak, where the software foundation originates, to just go through the valley of tears once so that you then have a system, when the software columns are set, that functions and that is stable. Then you should technically be at peace. But apparently that is not the case. Is there an error in reasoning in that logic? 

JB: Actually, no error in reasoning. But there is an important reason why that is the case. And it is that software is never finished. So, I am speaking of in-house developments now. And mistakenly, and a slight terminological confusion plays into that as well, you often actually still talk about software projects as if building a software was a project with a start and a clear end. If you now look at this off the shelve software, especially the implementation, then that is also the case. You want to use mail software in your company, then you buy Microsoft Outlook, install it, configure it and get the servers running. And in the end, you train the employees on how to use Microsoft Outlook. This kind of software, although this would rather be a software introduction project, is obviously a project. That is true. But in-house developments aren't projects. Why? I said it earlier. They represent the competitive advantage for the company, namely the business structure that stands on top of it. And now the world above naturally keeps spinning, new competitors come up or you have to adjust the existing services and products or you want to seize totally new business opportunities or new markets and new clientele is to be addressed. And all that means that the foundational software columns beneath need to be adjusted, expanded and equipped with new functions. I already said it, the catchphrase digitalization. In today's times of digitalization and with these times this kind of change dynamic again jumped upwards abruptly. That means that I constantly have to do reconstruction work on my software columns. Maybe I can give you a few numbers to illustrate the extent, on what scale this is happening. A lot of people probably don't know about this. Zalando for example has 1000 software developers in Berlin that take on software foundation changes every day. Or I have already addressed the system of the Deutsche Börse, the high frequency trading system. 600 software developers work on that. Spotify employs 800 software developers. So those are huge software companies. They don't call themselves software companies, but they are actually software companies. 

4. The core problem: lack of excellence in software development 

JK:Yes, I mean I remember some nice examples from when we worked together, and you tried to illustrate to people how complex software is. And then I still know how you once told us that if you were printing out and piling up all software of a normal, medium-size insurance provider, it would be as high as a 30-floor skyscraper. Yes, you have to think about that. There you get a feeling for that complexity. I basically have content that is distributed on so many pages that I can pile it up 30 floors high. But if I understood you correctly now, then the problem is kind of that all these earlier mentioned software problems are based on the fact that companies don't have a handle on the topic of software development or rather software advancement, as one would have to say by your logic.

B: Exactly. Right. You can basically trace all these reports in the media, the software errors, back to the fact that software advancement is not working. That is actually the key problem that you need to build more and more innovations into this software and without having a handle on the software advancement. Incidentally, that is the continuing trend. So, I talked about banks and insurance before or machine engineering companies. All of these companies are transforming more and more into software development companies. And unfortunately, these companies lack the proper excellence in that field. Maybe I can give you a few examples on how exactly this happens. Automobile companies or companies that come from the machine engineering sector know quite well how to build hardware–tangible products. In terms of these processes, they work on the highest level. But they can't translate that to software building. Incidentally, that is also the reason for why Volkswagen, for example, is afraid of Tesla. Or let's move to the financial sector, the insurance sector, the old economy is partly being overtaken by Fintechs in certain areas of business. Why? Because the Fintechs have a better handle on software development. 

JK: Do I understand that correctly then? Can we have a little bit of hope that it's one of those legacy topics that you basically just have one of those old economy dinosaurs that hasn't quite found its footing in this whole area of software development yet while the new digital companies don't have as much of a problem with it? 

JB: Software development is a problem fundamentally. So, it's basically the opposite of trivial to do it, for old economy as well as for those so-called digitally born software companies, the ones that basically understand from birth that software development is one of their core businesses. You talked about that already. So, source code, if you were to print it out, that huge paper pile with lines of code in it, as high as a skyscraper, many, many floors, it's abstract matter. I can't make it visible or graspable. That is the big difference to other engineering disciplines. So, for example, if I think about a factory hall where software is being produced then that is something completely different from a factory hall where I build gas turbines. So, in the software factory hall, I see 300 desks and 300 software developers that go at it on their keyboards. And in the gas turbine factory hall, the things that happen are also highly complex. There I see conveyors arranged in a complicated fashion, where parts are put together, screwed on, welded. But the fabrication process, despite its complexity, is still relatively easy to overlook. Why? I can go everywhere, knock against it, I can examine intermediate results on their quality and functionality. That means because it's all not abstract, but touchable, I have a better handle on it. That's another thing. With software, it happens all over the world. I don't even have a factory hall that I can enter and where I can talk to people, but 20 percent of developers are situated in Bangalore in India. And then I have 30 additional developers in Regensburg and a few in Berlin or the Ukraine. So this image of the software factory hall really is very, very simplified. But even if I had that, if they were all sitting in a factory hall, then the management is many times harder than with a gas turbine factory hall because every step that happens there is only reflected in abstract matter. That means that it is extremely hard to track the development process with all these many, many process steps. And if I can't even do that, to track the process, then it's obviously hard for me if I want to optimize the whole work process in terms of efficiency and quality. Then one or two years probably have to pass until the discipline of software development as software engineering, as an engineering discipline, gains the same maturity level as older engineering disciplines. So, at the moment I can say with a clear conscience that software development is at least a decade behind. And to be the person in charge of such a factory hall, for a software development organization, that is actually not a desirable job. Only few people do that. Or rather, let's put it this way. It's extremely stressful. Why? You carry a lot of responsibility because the success of the core business depends on your own success. At the same time, you have very few possibilities to see what happens in your own factory hall.

5. The classic metrics of Cost, Scope, Time and Quality 

JK: Yes, I have also learned that as a CIO, you can pin the first year on your predecessor, the second year a little bit and in the third year, you have to deliver. So, it is very understandable that you carry a lot of responsibility indeed and you manage a highly complex product that is extremely business critical. But I will put it this way, if software errors cause so much damage, shouldn't we focus on putting a software release through its paces before providing it to customers? Isn't that basically the solution so to speak? 

JB: Yes. So that was actually the focus that was applied earlier on with the so-called waterfall method or methodology. You would actually rather ship out software releases later. So shipping out means to provide it to the customers, either played on the productive servers or give out the installers. So rather rarely, maybe once a year, once in a quarter at most, but then thoroughly tested. For example, large testing divisions, 40, 50 testers, that test all software features again four weeks before the release go live. But you already see that rare supply is in contrast to other dimensions that you want to achieve. If I optimize solely with quality in mind, then I basically generate collateral damage in another dimension, namely the delivery speed. Then you have dichotomies, speed versus quality on the one hand.
I can take a lot of time and ensure error free software with higher certainty. That's what comes in with agile transformation, agility. Or I deliver fast and often, and I put up with the possibility that something might go wrong. Which methodology I use, waterfall or agile, that obviously depends on the kinds of software systems. So, if I take a really foundational backend software column deep inside the core banking system, then I will probably adjust it in terms of quality, or accuracy. If I have an app where it might not be so bad that there's an error in there, where I have to react very quickly though if I see that a user wants to have it a little differently, then I would rather use the agile option. That does not mean that in terms of waterfall vs agile, agile is always the better option. You rather have to see where you apply it. And additionally, I already mentioned speed vs quality, so opposing dimensions that I can obviously become faster with the waterfall methodology as well by automatizing test phases. So, the key word test automatization is what all companies work on. So instead of having 40 or 50 testers, I run it through robots, scripted programs. Then it obviously goes a lot faster. But the dichotomy still exists, on a different level. If I broaden the scope a little bit and look at other target dimensions that I want to achieve in my organization, then the dichotomy remains. So which dimensions are those that I want to look at additionally? First, I want to create user value, functionality and features for the end user. Second, key word cost, I have a restricted budget. Therefore, I obviously want to use every single development hour optimally. In the light of this, it is still an assessment whether I use my developers' time for building innovative software features and, subsequently, make the users and the actual customers happy, or whether I invest in quality by having the developers write automated tests for example, so I invest in the test structure, in the developmental infrastructure, but I have less time for the actual user values. Now I have talked about four dimensions already. And all in all, you can say if I take responsibility for software development and I want to manage it, then that basically means that I have to constantly balance it in regard to these dimensions. So that would first be costs, meaning the total budget that I have for my development organization. The topic of scope, so the amount of user value, of features that I manage in one release. The topic of time, the time span in which I can release and provide to the user. And the fourth dimension would then be quality, so the risk minimization so that the shipped releases contain as little errors as possible. 

6. The role of "technical debt" 

JK: If you hear that now, cost, scope, time, quality, you immediately think of the image that you know from management literature, the triangle from the classic product management. In the corners of the triangle, you have cost, scope and time and quality in the middle. And the message is basically that you can't have it all. If you optimize one of the dimensions, then you have losses in the other dimensions. Now you said before that the production of software is not really a project. And somehow this seems to go in the direction that it's actually classic product management. 

JB: So, if I look at the creation of every single software release, then I can look at it as a product. Here I, once again, have a clear starting point and a clear end point to use the metaphor, the image of the carrying software columns again. With a software release I have rebuilt the software column once only and with that, I have created new possibilities for the business structure on top of it. But as I said, I am not finished then. It goes on with the next release, the one after that and the one after that. It goes on endlessly. With this endless stringing together of small projects, a very, very important new dimension comes into play. And unfortunately, it is often neglected, and it causes problems. And for me, that is the inner structure of the software. So, if I only ever mind my four dimensions cost, scope, time, quality in my many, successive release projects, then it is very likely that the inner structure of the software becomes marauded. Maybe metaphorically speaking, so if I hit the software column too hard during the release rebuild because I am under time pressure, then I get small cracks in the structure. Or I have to build in functionality, but I don't do it in a way that I first build the column structure cleanly and then put the new functionality on top. Rather, I plant the functionality somewhere on the side with some adventurous auxiliary construction beneath just so that it somehow stays together. In terms of every single release, so the project perspective only, it might have actually been the right decision. In the end, you have probably succeeded in complying with these dimensions of cost, scope, time and quality. But all subsequent releases suffer from it in the future. The term that has been established for this in software development, for this neglect of the inner structure, is technical debt. Sure, I can neglect the inner software structure with a release. But I have to know that I have to pay interest on this debt that occurs through that in the following releases. And interest specifically means that I suffer losses in efficiency, and I waste precious developer time having to work extremely carefully so that the software column does not completely crash because of this inner cracked structure. So, these kinds of examples are very common. A bank might say for example, “Over the years, we have only built in time under stress. We have never been able to do inner cleaning-up operations or such refactoring or been able to invest in the inner structure.” And then the bank often reaches the point where they say, “We have to throw away this software column, this marauded something, and we have to build it completely anew.” So, from a business perspective that is a complete disaster. That means that I have to throw away all investments that I put in there and I have to invest from the ground up again. Exactly because of that it is immensely important that I keep this technical debt as an additional dimension in mind next to the other four dimensions. By the way, speaking about terminology, in order to avoid terminological confusions, I have mentioned the term quality earlier purely in the sense of software without errors. You can obviously also apply this quality term to the inner structure of a software. Then you would talk about code quality. I don't do that here deliberately. I rather use the term technical debt in order to keep the terminology clean so that it stays somewhat understandable. This whole topic is already complex enough. 

7. Efficiency as a sixth dimension 

JK: Yes, indeed. Now we can see that there are already five dimensions. Let me put it this way, the interest payment that I have to make on such a technical debt, that is what you talked about, you could technically say that those are to some extent efficiency losses in the whole process. 

JB: Yes, exactly. So the money and the developer time that I waste because technical debt exists and the developers simply have to be slow, as they should be by the way so they don't break anything, I don't have at my disposal anymore in order to build features for the user. It really is a highly inefficient use of my budget. And of course, there are more reasons for efficiency losses. For example, at the start we talked about software errors. They aren't simply bad because the user can't properly work with the software. They are also bad because software errors mean that I suffer massive efficiency losses in subsequent releases. I have to use up precious developer time in order to correct these errors. Again, you have less time for the actual goal, namely creating a lot of user value. Along with these two causes there are many other causes for efficiency losses. That is, when I am in charge of a software development organization, I should always keep the dimension of efficiency as a sixth dimension in mind, especially because that is also the dimension of the money that gets lost if I as the one in charge of a software development organization want to communicate things to the highest management, the board for example. Everyone with a degree in business can understand that. 

8. The seventh dimension: distribution of knowledge. 

JK: Okay, so if I want to run a software organization on highest excellency, as we have just seen, there are six dimensions, namely cost, scope, time, quality, technical debt and efficiency. I have to keep all of that in check in order to optimize it. Is that the whole set already or are there other things that need to be added in your view? 

JB: Yes, software development is actually a little more complicated unfortunately. There is actually a seventh dimension. That's the optimal distribution of knowledge among the developers. Why is that so important? Maybe I give you a bit of background. So, the question is which developer knows his way around which part of the code. Which developer can jump in when there is more work in a certain part of the code? For that you have to know that the code is not immediately code. For one, there are different programming languages and frameworks. So, a typical software column in the banking sector would look like this for example. In the middle of the column, the so-called middleware, you usually have the programming language Java. Then down in the pedestal of the column, in the so-called frontend, you usually program with Java or Typescript. So if, for example, you had a lot more work down in the backend in a release because of some specific user requirements, then you can't simply get the frontend developers because they don't really know their way around it. So simply because of these different technologies and programming languages already I have to know how much capacity, how many people have the skillset to do these things. And when you look a little closer now, it is even harder to get a handle on it. Why? Because even in the same language and technological world, there can be monopolies of knowledge. So metaphorically speaking, you can maybe think about it as a plate full of entangled knots of spaghetti that all intertwine. And you don't know what impact it might have on the whole thing if you pull on one noodle. So, these kinds of codes really exist, quite commonly actually. Small excursion. With banks, for example, there is still a whole lot of code left over from the 80s, COBOL, PL/I, programming languages that aren't even being taught anymore. At the universities, people aren't being trained for that. This kind of code still exists in great numbers in companies and it will continue to exist. You can't throw away that software column. Sometimes you do it out of necessity. But if you can, you keep them. That means that this kind of programming language remains. That means that over the years and decades there are many, many spots in the code that look more like a plate of entangled, intertwined spaghetti. And then, most of the time, with high probability I just have one software developer that works in that because they are that developer who knows their way around those complex code spots. They know the perils. That means that he or she is even somewhat efficient in what they do. The problem is then if that software developer is absent, for example they get sick or they leave the company, then the whole software development stands still. Yes, that is then a huge problem for the software development organization as a whole. I can't just have another developer do that work. That is also the reason why it's not enough to look at these six dimensions. Rather, you have to keep the topic of knowledge distribution in mind, namely cost, scope, time, quality, technical depth, efficiency and knowledge distribution. So, if I have a tight handle on these dimensions, then I would say that I have a decent change to get my software development organization on course for highest operational excellence. 

9. Software Analytics and KPIs 

JK: Alright, so to stick with the culinary example, we are developing a good recipe here for how to lead software development to this excellence. I have to keep these seven dimensions in mind and optimize them specifically. What would you say, what tools, instruments, platforms give me such an overview? So, at the end of the day I need a lot of knowledge. 

JB: Unfortunately, I have bad news, but I will give a flicker of hope at the end. I have already mentioned that software engineering as a discipline is far behind the traditional engineering disciplines in terms of time. In automobile manufacturing, for example, they work on the highest process level with the lean manufacturing approach invented by Toyota since, at the very least, the 80s. Why? Because, apart from the actual tools and conveyors and everything that you need to put together and weld together a car out of the separate parts, they also have tools and platforms running with which they can supervise how the whole process functions from start to finish. And with that, I can also optimize the whole process of course. That is a must-have in automobile manufacturing. If I didn't have that, I wouldn't stand a chance in the market. And in the world of software development we haven't reached that point yet unfortunately. I will try to present a quick historical outline of software development tools. In order to make a little more graspable for outsiders what tools are actually good, I will again attempt a metaphorical translation. So, the first tools for software developers were basically compilers and programming environments, hammer and screwdriver so to speak. One prominent example for programming environments from the Java world would be Eclipse. After that, Version Control Systems arrived where source code was administrated systematically. So, basically, metaphorically speaking, they are the storage, shelving systems in which components are organized on a large scale. Examples for that are IBM Clear Case, which is still being used a lot today even though it is from the 80s, Subversion, or nowadays most people use Git, namely those that are digital born. Then the next kinds of tools and instruments are the so-called image automatization systems. Today you would call them CI/CD systems, namely Continuous Integration Systems. What they do is that they take the source code, the source text and they automatically transform it into feasible components. Metaphorically speaking, they are basically robots that drive to the high-bay racking, take the components and put them onto the conveyors and the robot arms that then assemble the functioning car. In the software world the most prominent tool in this case would probably be Jenkins. Then came the time, I talked about it earlier, of manual testing that have become more and more automated, time of test automatization so to speak. There you would start to hook up test tools and code checkers with these CI/CD systems. So when the source code is transformed into feasible system components, at the same time, you test with testing devices whether the components, either single parts or those that are already somewhat functioning going past on the conveyors, that you are in the process of assembling are faulty. Now concrete tools in the software sector are Junit and Framework for example in terms of test automatization or Sonatube in the context of code checkers. As a last category that has arrived on the scene, tools for better coordination of factory orders, those are the so-called issue tracking systems which contain the piles of factory orders. And the software developers take such an order. Then they go into the component storage and they take the components that are to be expanded to their desks. Namely, they check out the code from Git. Then they augment the changed component according to the requirements in the factory order. Then they take the changed component back to the shelve. Say, the changed code is getting checked back into Git. And a tool for this issue tracking that has established itself as top dog is Jira. And that is basically it. That is the status of software development nowadays. Everyone involved in the software development process is quite well equipped with tools that he or she needs in order to be able to do their work well. There is a lot. The names that I just mentioned, I have only named a few examples, so the whole ecosystem of tools, there are hundreds of tools, thousands even, the hammers and screwdrivers, special pliers and so on. There is a whole lot. And that means that the people individually are extremely well equipped. That would be my conclusion. Bad news is that no possibility has come around in the software development sector to see the process as a whole from beginning to end and to then conduct optimization work when I can see that, when I have that transparency, so that I can more and more optimize my development organization. We don't have that yet. There isn't even a term for categorization for these kinds of tools and platforms. So if I was responsible for a big software development organization and my seven dimensions that we have talked about, if I want to keep those in mind, then I wouldn't even know what to search for in Google in order to get help. That is where software development is at the moment. Now I said before that there is also a flicker of hope. That would be the following. If you now look at what is happening at universities, that is always a look into the future what might be common in the industry in maybe five to ten years. You can see there that they are making the first methodological approaches. I myself, I said it at the start, am concerned with the topic for nearly 20 years now. So, I have a pretty good overview of what is happening in universities, or academically. And when we started back then, we were completely on our own. And nowadays a lot more is happening in universities with regards to this topic. And there are big platforms coming out of those universities that I can use on a large scale for real, big, industrial software development organizations. And what these platforms do is the following. They analyze which data tracks these 1000 tools that I talked about earlier leave behind. Whenever I run a CI/CD system through it, data tracks occur. So basically, there is a lot of data gold down in the basement. This new kind of category of platforms now uses this data gold in order to reconstruct the real, lived development process out of these data tracks, with all its flourishes and inefficiencies. So basically, complete transparency over how well the shop is running and what is really happening in the factory hall. What happens afterwards is that the data tracks are of course ground truth, the truth. Yes, that is not just something that some person mentions in their report and they say, “Yes, the situation is quite alright.” Rather, this is ground truth data. And they are being used to deduce KPIs, key performance indicators with which I have indicators on a higher level with which I can record these seven dimensions that I talked about with objective numbers where I can really grasp the situation in a quantified manner and observe it as well. Finally, it is important to create some kind of digital boardroom where I put the real KPIs that are important to me according to my seven dimensions so that I can see every day in real time where problems come up in my factory hall and where I might have to intervene, either as the one with overall responsibility of the development organization basically. That might be a bit of the old image, the factory head who stands above it. But that is not the culture in software development anymore. Rather, it is a collaborative effort. The team as a whole works and decides, especially in the agile world. But nonetheless I need this kind of transparency. There I have objective numbers for everyone involved in the software development organization on my digital boardroom where everyone sees, “This is where we are at. If we now run the release projects through with so much time pressure, we keep accumulating technical debt. Say, you should include that for the next release cycle that we plan with such a debt depletion.” I can only make these kinds of decisions consciously if I see how the KPIs change. In my view, that is an opportunity for how to actually get a handle on software development. I said earlier that there is not a proper term for categorization for this. It will probably take another one, two, three years until that happens. Nowadays you would come closest, if you wanted to google it, with the key word software analytics or software process mining. That would come closest. I am also in exchange with the big analysts like Gartner or Forrester because they order these tool worlds, basically the yellow pages of all the tools and vendors and providers that exist. And even they don't have a term of categorization yet. But Forrester are even a little ahead of Gartner. They already have some kind of new wave, an initial starting point to develop categories in this direction. But as I said, a lot will happen in that regard. Jumping back to the start of our conversation, we began with software errors. And my personal opinion is that in the coming years, if you open the newspaper, nowadays you also do it digitally or through online media, there will continue to be reports of businesses crashing because of software. And that will continue to be the case until the common sense conviction prevails in these millions of software factory halls that are out there in the world, seeing as every business has software underneath it, that it just isn't enough to equip the developers or the people involved with hammers, screwdrivers, conveyors or robot arms. It's not enough for excellent software development. Rather, you need to do it like they do in machine engineering that you put data driven process optimization on top of it with these software analytics approaches that I talked about. That really is a must have for an organization that does software development. 

JK: Can you maybe conclusively give us a feeling as someone who works in the sector of software analytics how I can expect the work results that come out of such a software for software analytics. So, do I have some sort of heat map for my code afterwards or do I simply have a lot of numbers listed one after another? What kind of product comes out of that when you say that we have to create some sort of digital boardroom at some point? 

JB: Right at the top of the product is this digital boardroom that is basically a huge cockpit where I can see according to my dimensions that I have to balance where trends get better, where they might abruptly get worse so that I can intervene. So that I can at the same time become better step by step. Yes, basically like driving a car. Now I take another image. I have used quite a number of metaphors already. So, driving a car, there I have my dashboard. I can see on that how fast I am going. I see how much gas is left in the tank. So, some kind of cockpit where I can see what the condition is at the moment. With analytics, you can put it on some kind of digital dashboard, digital boardroom. That is actually only the first step. So, if you now look at what the dashboard of a Beetle looked like and what it looks like today, you don't see many of the indicators anymore because I don't need them anymore for driving. That means that the next step for software analytics is basically to detect on your own through machine learning when certain KPIs become negative, so some kind of early warning machine. That means that I don't actually have to look at all the indicators anymore. Rather, I am told by the system, “Caution, with the speed you are going with, in 99 percent of all other cars that took a similar turn, they crashed against the crash barrier.” So, some kind of intelligence from the system that warns you early so that you can pump the brakes in time. The next step of analytics would go even further that the brakes are confident enough, that the system is far enough developed that it autonomously takes the risk out by slightly slowing down. We still have a long way to go. So, software development and the management of software development, I think, still take some time until we can leave these kinds of things to robots, to mechanical intelligence. But nevertheless, it can function quite well as a supporting system. So self-driving car does not mean that I can sleep, nowadays it doesn't at least. Rather, I am assisted by these smart assistance systems, but at the same time I have to stay alert. So, on such a level I can imagine that we can arrive at that point in roughly eight years, ten years, depending on how well academic things can be translated into fleshed out products. 

JK: Very nice. I think, normally we can say that we now want to go through the concrete KPIs of these seven dimensions. But I think that would go beyond our scope. Nevertheless, it was a lot of fun. And I always like your illustrative metaphors. And I am even thinking about whether we should make a podcast series out of that topic, especially now that companies are really forced to be digitalized and whether that could be of help for a lot of people. So, the two of us can think about that after this podcast. And yes, apart from that, as I said, thank you very much, dear Hans, for these deep and really interesting remarks. And I hope that more people out there are now able to think about what excellent software development could look like and what might be needed for it. So, in that sense, thank you very much and keep us updated. 

JB: Very nice. Thank you, it was fun. Thank you very much.