Video transcript:

My name is Michael Schaffler. I'm responsible for technical management at CIIT Software and work on various software development projects. I also provide training for software developers, or IT professionals in general. Generally speaking, you can distinguish three different categories of software. On the one hand, there are unchangeable software products that can be purchased and then used by individuals or companies without the ability to adapt them to their needs. On the other hand, there's standard software that can be customized, meaning it can be adapted to a certain extent to meet the customer's requirements. And the third category is custom software. This is software that is developed specifically for clients and is essentially a tailor-made solution. Yes, there's a specific application area. If you look at accounting software, for example, it has to meet certain legal requirements. And it's quite clear that the accounting software has to function correctly because it's precisely defined which figures, for example, appear in a balance sheet or a tax return. And these requirements must be adhered to. For such a use case, standard software is ideal, and it would make absolutely no sense to develop custom software if the requirements are perfectly clear. On the other hand, at the other extreme, you have companies with a truly unique business model. Let's take a customer, for example, Vinpilot, which develops control systems for wine cellars that automatically manage the fermentation process in wine tanks. This software is highly customized. There are only a few companies in the world that need such software. And when there are various providers, they try to differentiate themselves through their software, offering their customers added value, additional services, and additional functionality that sets them apart from their competitors in the market. And that would be the other extreme. We have a unique use case, and furthermore, the company relies on designing its own software in such a way that it has a competitive advantage over the competition. And that is the domain of custom software development. Looking back, say to the 60s and 70s, almost all software was custom-developed. Then, during the 80s and 90s, standardized software became prevalent in certain areas because recurring requirements could be offered as products. More recently, companies have increasingly sought to differentiate themselves through their software or their online presence. For example, if they're launching an Amazon Marketplace, they can't simply use an off-the-shelf webshop program. They need to implement specific features, settings, and special offers through their software to provide customers with added value compared to their competitors. The number of companies trying to differentiate themselves through their software has increased dramatically in recent years, which is why custom software has exploded in terms of applications and the demand for software developers. Ultimately, it allows companies to improve their competitiveness in the market. Custom software requires a significant initial investment; having software developed is relatively expensive. Ultimately, it's an engineering undertaking. However, the advantage of custom software is that, if you have a corresponding contract with your software supplier or develop the software yourself, you then own all rights to it. For example, we offer our customers the option to acquire the rights to further develop the software. This means that the initial investment is made once, and then you own the software. If you want to scale up, to return to the question, you don't incur any additional costs; you simply need to be able to use the software without having to pay for additional licenses within your company. This is an incredible advantage over off-the-shelf software. You know that. Or do we all know that manufacturers and providers of standard software are increasingly trying to move towards a subscription model? In other words, all software providers have tried to switch from purchasing licenses to offering subscriptions. Some providers no longer offer outright licenses; instead, you have to subscribe. These subscriptions are typically user-based. This means you pay per user and per server, and so on. The major drawback of subscription models is that as soon as you want to scale, the costs to use the software become significantly higher. This is a key advantage of custom software. If you have custom software developed and you own the rights to it, you can easily adapt it at any time. New market situations arise that require a quick and innovative response. For example, if you want to establish a new business model, you can easily do so with custom software by simply extending its functionality. If you opt for standard software, or even a custom version of standard software, you are ultimately dependent on the provider's willingness to develop the software in a specific direction. And it can happen very quickly that the provider simply doesn't develop the software in that direction. Even if he does, all your competitors have also implemented these features. This means you can't differentiate yourself or are even hindered in your development. In other words, they simply can't implement certain features, and then you have a choice. You can say, "Okay, I'll go with another provider." But if you're stuck with the standard software provider and ultimately want to switch, you'll face enormous migration costs, which quickly reach a level where you could have developed it yourself. That's precisely why custom software offers much, much greater flexibility, enabling all kinds of projections, extensions, market responses, requirements, and so on. Yes, that's indeed a very good question. Custom software also has the advantage of being integrable into any system. The software industry has advanced to the point where it offers a machine interface for virtually every good software application—not just a human interface, but a machine interface through which other systems can be connected and integrated. And this is something that can be used very effectively in custom software by simply connecting to the company's existing systems. It doesn't matter whether these are standard systems, highly complex systems, or other custom software systems. I can integrate everything. Of course, there are also specialized integration solutions and so on. But fundamentally, it's easily possible to offer interfaces for other software systems that want to connect, or conversely, to access other software systems. Here, too, we have the flexibility to integrate anything into the software at any time. Yes, when it comes to automating work processes, it must be said that custom software has a unique value. Why? Well, we have... Or, one can distinguish between different types of software. On the one hand, there's the software I need for my customer relationships or my external presentation. That's one aspect. These are software products or custom software that can improve customer relationships or the services I provide to the customer. On the other hand, every company naturally has purely internal processes. And it must be said that companies differ from each other just as much as in their public image. If I use standard software in my company, it ultimately always means that I have to adapt my existing processes to this software. In other words, the software forces me into certain processes, and this can lead to a significant loss of efficiency. Because to function optimally, I want to be able to design my processes as I deem necessary, or as management deems necessary. With custom software, I can adapt it to the processes and thus optimize them. Therefore, the use of standard software often hinders the optimization of internal processes within a company. The duration of software development naturally depends heavily on the complexity of the software. And we always recommend that our clients start with the simplest possible version of the software. For simple software systems, which we want to develop as quickly as possible, we have a lead time of, let's say, a few weeks—one to two, maybe three months—and then the software is ready to use. So, unless you order a new sofa today with some customization, you'll probably have a longer delivery time than if you find a well-functioning, highly experienced, agile software company and have them develop the software for you. They can be very fast. Of course, you need very complex systems that include many features, and complex features at that. These can naturally mean correspondingly longer development times. The functions of a software are always specified by the customer, and we, of course, provide the customer with consulting support. The customer always has a wish list of what the software should be able to do. And prioritizing these customer requirements is one of the most important steps. And in the software development process, the approach is always to implement the customer's highest-priority requirements first and then continue development until you reach the finer details of the software. Then, features that are merely "nice to have" might be addressed later. This means prioritizing the most important functions, developing them first, and then the customer immediately benefits from their software. Several aspects are crucial for choosing programming languages and, consequently, the entire programming language ecosystem. One aspect is, of course, the innovative capacity of the respective platform. That is, how quickly does a platform adapt to new requirements? Let's take AI as an example. Then I can ask myself: Does my programming language offer frameworks, libraries, and other resources that I can use? In software development, am I able to implement an AI-based solution? Or am I able to develop cloud-native applications—applications built to run natively in the cloud? Am I capable of developing such solutions with this language? So, ultimately, technical feasibility is a prerequisite for all new developments. Naturally, this involves using widely used platforms. Why? Platforms with a large user base are always much more likely to adapt to modern developments. That's one aspect. The second aspect is the investment security I have in the technology. What's crucial when developing software is that the underlying technology—the programming language, the operating system, the libraries, the frameworks, and so on—remains available in the long term. Here, too, the size of the providers who supply these core technologies plays a role. Ideally, it's open-source software, meaning that even if a company eventually ceases operations or evolves in a different direction, it continues to exist and is further developed by other companies. There are numerous examples of this in the software industry. And the third aspect is the availability of experts in this field. If you want investment security and software with a long lifespan, you also need people who can continue developing that software. And that's precisely why it's so important to choose a technology that's widely mastered. That means one that's taught at universities, recognized as a good programming language or framework, and so on. Essentially, you try to go with the flow and attract the right people from the job market, ideally those who have already learned these technologies during their education or professional experience. And then, of course, they have significantly less training needs when they want to bring new employees into their company. From a customer's perspective, this means that if I, as a customer, have software developed and I'm not satisfied with my provider, and I'm using a widely adopted technology, then I can very quickly switch providers and say, okay, now I'll find another company, because the likelihood that other companies have mastered this technology is correspondingly high. So, the three things I would pay attention to are: First, a modern technology that allows me to realize the technical feasibility of modern technologies. The second point is a technology that offers high investment security because it has a high probability of still existing in five or ten years. The third point is the availability of specialists in this technical field, specifically in this programming language or at this frequency. The main reason why standard software needs to be covered is, of course, security. Vulnerabilities and security gaps become known, and these vulnerabilities, as soon as they are discovered, are exploited by malicious individuals, i.e., hackers. With custom software, security is also an important reason for outsourcing the software, ensuring that the technologies involved are covered in all versions, especially if security issues can arise. However, the most common reason for outsourcing the software is actually the further development of its features. This is something that is highly valued by the software's users and customers. For example, if you offer software to your clients... Let's stick with the example of controlling fermentation processes in wine cellars. If you release a new version that simply includes a new feature, your customers will be pleased and feel vindicated in their decision to choose this software. This means that the gradual expansion of functionality is a crucial element in generating customer loyalty and satisfaction. Everyone who owns a car knows this, whether it's being updated or having its operating system updated. We appreciate every small change that offers a personal benefit and are happy to receive a minor update for our device. And with Individual Show, you can achieve this to a very high degree and very quickly. Because if you receive feedback from your customers about how they use your software and what they would like to see changed, you can implement it immediately with your development team. With standard software, this implementation is often impossible. Or you have to wait a very long time until, hopefully, that feature is eventually implemented. Software systems are inherently complex, and all complex systems have errors. Therefore, bug fixing in software systems is a continuous process. We all know that even companies with billions in revenue, like Microsoft or SAP, have bugs in their software. Even car manufacturers, for example, have truly gigantic budgets and still don't discover all the errors. And of course, with custom software, it's often the case that bug fixes require more effort than the development itself. This is certainly not true. Especially since software engineering has made significant progress in quality assurance in recent years. This means that quality assurance is now highly automated, thus reducing the error rate. Software quality is ensured through a variety of quality assurance measures. These include constructive and analytical quality assurance measures. Constructive measures would include, for example, ensuring proper training and professional development for employees. Analytical measures would include, for example, using the right tools and having a defined development process that precisely specifies the steps involved in software development and how the software's quality is ensured. Yes, and analytical measures also include conducting tests. What we do today is develop a test for every piece of software that automatically tests that component. This is called test-driven development. Conceptually, it means that before you even write any software, you write the actual test and only then write software that ideally passes that test. That's what test-driven development is all about. And with every change to the software, all these automated tests are run again and again. A major source of errors is changing the software itself. This means that you modify the software and inadvertently introduce errors. These automated tests ensure that if you make changes to the software and accidentally introduce a different functionality with a bug, they detect that bug. So, with every small change to the software, the entire functionality of the software is fully automatically tested within minutes. These are automated integrations or units. It's crucial to make this an integral part of the development process. Other aspects that fall under constructive quality assurance include automating as many steps in the software development process as possible. This means minimizing human interaction to implement the software, which significantly reduces the error rate. Another analytical quality assurance measure is code reviews. What are these? When a developer writes code, it isn't simply integrated into the existing code. Instead, a code review takes place, where a colleague examines the code closely. This is standard practice for all major software products. For example, operating systems or other widely used technological products have established peer reviews in all these companies. This means that someone reviews the software changes and identifies potential errors. That's what a review is. There's also the option of automated code analysis. These are tools specifically designed to automatically find errors in software. And of course, modern AI components are part of that, which then intelligently find errors in the software. Well, and then, ultimately, you have tests that are carried out by people at the user level. And it's best to have real users do that, because they use the software the way real users use it. Or rather, they make the mistakes that real people make when operating the software. And they often reveal weaknesses in the software. That's why human testing, end-user testing, or whatever you want to call it, is always important. Then there are other aspects of the software. So, those were more the functional aspects of the software. There are also non-functional aspects. For example, performance, response time, would be the scalability in terms of the number of requests the software requires. Specific tests are also carried out for this. This means the software is artificially subjected to stress, and then its response speed is observed, specifically where the limit is reached and the software no longer functions correctly. Finally, of course, quality assurance measures related to security are implemented, so-called penetration tests. This involves specialized software that can test application interfaces or software for vulnerabilities. For example, can I read a data set without being logged in? Can I circumvent authentication in any way? These are the kinds of tests that are performed. The purpose of these tests is to identify security vulnerabilities. As you can see, there's a whole range of different tests used to make software secure and error-free. All these methods are used in custom software development to achieve the highest possible software quality. Open-source software, on the other hand, is based on the idea that certain software can be shared with others during development, or that the development effort can be shared. That's one aspect. Many companies invest in open-source software, for example, operating systems like Linux or Android, or database technologies, and so on. They all share the development costs, without complicated billing models or anything like that. That's one aspect of open-source software. The idea that open-source software is developed by private individuals is only partially true. Large open-source projects are financed by large companies that expect to benefit from it collectively. Another aspect of open-source software is that software manufacturers try to achieve widespread adoption through it. If I offer software for free or make the code available, I ensure that many people use it because it's free. Many providers then charge for certain features, representing premium functionality. In other words, open-source software is a vehicle for companies to achieve widespread distribution of their own software and thus increase their market share. This is very evident in the Linux world, for example. And ultimately, there's open-source software, open source, open-source software, developed out of a certain idealism—the idea that software should be a common good, benefiting all of humanity. This idealistic drive for open-source software is particularly strong in the Linux world. But you also see it to some extent in very modern companies. For example, Tesla, with its CEO Elon Musk, has made many patents public and offers these otherwise protected intellectual property assets as a public good, simply because of their ideal of electrifying the world, or rather, the world of mobility. This means that this ideological component is also very common in the open-source movement. Overall, it must be said that individuals have become particularly significant beneficiaries of this open-source movement because, through the integration of open-source components, they can produce good, high-quality software relatively inexpensively. Yes, collaboration within a software development team can be visualized as having different parts of the software where work can be done. If I compare it to building a house, for example: one worker installs the windows, another plasters the walls, and yet another paints them – there are dependencies. Obviously, I can't have a painter paint a wall that hasn't been plastered yet. But fundamentally, there are different parts of the code where development is taking place. That's the typical way of collaborating. Different developers are working on different parts of the code. Of course, a developer might depend on code from other developers, which they call, use, or whatever. And then, of course, there are dependencies, which is why very good communication within Steam's software development team is crucial. This includes daily meetings where everyone agrees who is working on which parts of the software. And the employees in this active software development methodology do this independently. This means everyone decides for themselves which tasks they want to work on. And that greatly boosts employee motivation. Of course, the interaction and integration of the various work packages also creates a technical dependency. This means that if one developer changes the code, it doesn't necessarily match the code of another developer. And when I combine the code, the software as a whole still has to function. Quality assurance aspects play a role here, but above all, the right tools are crucial. There are software version control systems or software solutions, control mechanisms, systems that are capable of signing the software being developed, so that I can always revert to older versions that are also capable of integrating the software components created by individual developers, resolving conflicts, and so on. So, it's about tool support, but also, very importantly, the right approach. Over the years, software engineering has established standardized processes for how such collaboration can take place. Today, software development teams are limited in size. It's generally assumed that a software development team can only work effectively with a maximum of 10, 14, or so people. Once this critical size is exceeded, efficient development becomes impossible. Therefore, and this is also a motivation, to divide software into smaller parts. Each development team is then responsible for a single service. This approach has a name: microservices architecture. This means that the software isn't developed as a monolith. Instead of writing one large piece of software, it's written in small pieces. These many small pieces are then integrated together. Each development team is then responsible for a specific piece of software, a microservice. This enables scaling in the software development process. Otherwise, developing very large software projects becomes extremely difficult. Yes, I'm very satisfied. We have a very high degree of employee autonomy. That's actually the most important thing for a company to deliver very high quality and very good, efficient performance. It means that employees simply enjoy their work and find fulfillment in it. And typically, this happens when they can decide for themselves how to solve certain problems. And that's actually our philosophy: to foster employee autonomy. And that's a privilege you have, especially in small, agile companies like ours. Large companies suffer greatly from this. Or rather, I should say that employees in large companies suffer particularly from being trapped in processes imposed on them, where they function only as a small cog in the machine and consequently lose a great deal of autonomy. And from my many years of experience in large, medium-sized, and small companies, I know that when employees feel they can't actually make their own decisions, but are always being dictated to from the outside, then this can negatively impact a company's offerings or productivity. And that, I believe, is what I'm particularly pleased about in our company: the exceptionally high level of employee autonomy. And that's what makes us successful. Ultimately.