How are there bad programmers?

Good software has its price. Bad ones too.

Software costs money. And bad software can cost a fortune. Even the largest companies like Deutsche Post or Lidl are not immune to problems and have burned millions in recent years. The examples are terrifying - and often avoidable. We say how.

Deutsche Post is one of the ten companies with the highest turnover in Germany - and has to struggle with outdated, outdated IT systems on a day-to-day basis. "We have an aging and heterogeneous IT landscape," the group admits to the industry magazine "trans aktuell". Problem recognized, problem eliminated? Unfortunately not. As a result, Swiss Post started the “New Forwarding Environment” (NFE) project. This was to replace the more than 30 year old IT system “Logis”. The project failed, more than 500 million euros had been burned and Wirtschaftswoche had the headline: “The computer chaos of Frank Appel”. Processes should be standardized and instead of a DHL employee being responsible for a customer's order, the order should automatically move through the new system and thus through the departments. Ultimately, it only meant that nobody felt responsible anymore. Filling the system with customer data also caused chaos. Initially, this should be done by the employees - then the task was assigned to an external company without specialist knowledge and errors increased. Every error in the database caused subsequent errors and made the system unusable. Although the IT system was not yet working properly, the department began to be rebuilt and the chaos was perfect. The responsible board member wanted to take the last step before the first, says a former DHL manager in Wirtschaftswoche.

“WaWi” and “Elwis” - billion dollar grave at Lidl

The food discounter Lidl also had to struggle with software problems. The company's own inventory management system “WaWi”, which was getting on in years, was to be replaced by a new SAP solution. A few years and 500 million euros later, “Elwis” (electronic Lidl merchandise information system) is history again and Lidl has decided to continue developing its own software. The decision was made beforehand to use a SAP retail solution to simplify the administration of 10,000 branches and 140 logistics centers. It was tried with great effort to adapt this system to the Lidl specifications. SAP Retail usually works with purchase prices, but Lidl works with sales prices. What sounds like a small thing was a fundamental change and it went against the grain of the system, caused incalculable risks and costs - and ultimately led to the termination after seven years.

A2LL - a failure story

There are annoying software problems, but there can also be drastic consequences for those affected. This is what happened with the introduction of A2LL, which stands for “Unemployment Benefit II - Subsistence Benefits”. The software was used from the beginning of the 2000s until 2015 - with massive start-up difficulties. The software for recording and managing financial benefits for aid recipients was planned. Many mistakes had crept in. For example, account numbers were “filled in” the wrong way round, so that the account number 123456 became 123456000 - the correct number would have been 000123456. As a result, payments could not be assigned and did not reach the intended recipient. Cash checks were used to solve the problem - however, the street names were incorrectly abbreviated, so that the service did not reach the intended destination. Within the first year, the software again transferred 25 million euros too much in contributions to various health insurance companies. These suffered from complicated chargebacks. The reason for this was that current legislative changes could not be entered into the software promptly. The successor software “Allegro” is now running and causes fewer problems.

What we do differently

What can these examples show? No company is protected from bad software. We take these difficulties seriously and have developed some strategies over time to meet such challenges at an early stage. Nobody says software development is easy, but it is manageable and so we reliably achieve very good results together with our customers.

  1. Requirements management

    We have specialists who do nothing but deal with your goals and translate them not only into documents, but also into mockups and click dummies (see below). What does our customer want to achieve with the new application and who are the users? We can also talk about technology, but we don't have to. The most important thing for us is to understand your goals and the framework conditions. We are very familiar with the technology - if you like, we will explain what we implement and how, if not, we simply do it and you benefit from the result.

  2. Mockups and dummies

    With a fraction of the later project budget, the user interface of the later application, the so-called mockups, can be designed before the technical implementation. These mockups can be further developed into click dummies. These can be used to simulate the later behavior of the application without any programming effort. This allows users and decision-makers to see very precisely what to expect later, which means that the gap between expectation and implementation can be reduced to an absolute minimum. Small deviations cannot be avoided, but 1-2% deviations are completely unproblematic in practice and can still be corrected if necessary. Deviations of 20 percent and more would quickly be the end of a project.

  3. Iterative / "agile" approach

    We don't even try to land the big hit at the first attempt. All of the aforementioned projects have in common that attempts have been made to approach users directly with a large range of functions. This leads to long development times and thus to financial and functional risks. We plan small work packages from a few weeks to a few months, so that clients and users can quickly see where the journey is going, deficiencies remain manageable and can be quickly found and remedied.

  4. Software architecture

    In addition to the design of the surface, an application also needs a technical design. This defines how the planned functionality is broken down into components and how they exchange data with one another. Projects that fail are mostly so-called monoliths, in which an attempt is made to implement all functionality in a code base. This makes it difficult to work on a project with many people at the same time, as you quickly get on each other's feet. Everything also influences each other and if one functionality has a problem, the others usually also have one. It is better to break down a system in the sense of self-contained systems into individual, independent components, which, however, does not stand in the way of a common user interface. The online shops from Otto or Amazon are examples of such an architecture, but it can also be transferred to any other industries and applications.

  5. planning

    A particularly experienced programmer plans together with colleagues how to proceed in detail with the implementation and which technologies are to be used. Only then can the actual programming begin.

  6. Four-eyes principle

    We rely heavily on pair programming: two programmers work together on the same task. A bit like the police, one goes ahead, the other protects. So that nothing really goes wrong, there is a code review afterwards: This is where a particularly experienced programmer comes into play. He assesses the code, gives feedback and ultimately approves the code. In this way specific bugs can be avoided, but also “spaghetti code” and architectural problems can be recognized and avoided as they arise.

  7. Updates

    We never leave you in the dark. We also keep in touch with you during the process and keep you up to date on all important developments. Have there been any changed requirements, do you have any questions? We stay tuned.

  8. Testing

    Every new functionality that is implemented is intensively and conscientiously tested before we deliver it to you.

  9. business

    • Do you have your own admins and maybe even your own data center? Very good. We provide you with all the information you need and support you where necessary.
    • You don't have your own capacity to operate software? No problem! We take care of all questions relating to deployment, monitoring and backups for you. In short: everything that is necessary for the safe and stable operation of software.

Do you have any questions or suggestions? We would be happy to discuss your project with you without obligation and free of charge. Please contact us by phone or email!

PS: Software problems can also become a problem in space. For example, when a probe hits the Martian soil at 300 km / h instead of landing gently. But this is another story.

Who writes here

Pablo Beyen

Founder and head of bevuta IT - for 20 years now. If he is not yet fully occupied with software development, software architecture and data security, he deals with the topics of e-mobility, space travel and (digital) innovation. His mission: to make life easier and the world a little better with technology.

Always well informed

The bevuta IT GmbH newsletter

A confirmation email has been sent.

There was an error subscribing.

  • The direct line to what drives us
  • News from the company
  • Comments on digitization and product development
  • Strong in opinion and tough on the subject, but friendly in tone