Roland Dürre
Friday February 14th, 2014

Ultimative Software Quality!

The awareness for the relevance of “software” as a critical factor towards the success of an enterprise has increased. In Germany, too, the big concerns focus more and more on the IT-based applications and evaluate the quality of same in order to improve it.

For me – totally unstructured – the following questions come to mind:

  • Why are there still such big software projects with a hundred and more programmers?
  • Why do they still believe high specialization (requirement engineering, architecture, quality, implementation, configuration or project management, …) and division of labour in global development triangles such as India-USA-Europe is a way towards success and minimal costs?
  • Why does management never seem to learn anything from all the numerous failures and crises with so many IT projects?

Here are a few answers and theses for improvement:

  • Focus on the future!
    In order to create quality and thus gain truly precious software, I would recommend to first focus on the new software projects in the enterprises. Basically, this is a huge challenge per se. I would only touch the “old” applications where it is absolutely necessary (except if I have too many resources and too much money). Because, as a general rule, the organizational, systemic and inter-human problems are just too huge, which means that the improvement you get comes at a high price.
With new projects, I can at least start on the green field when it comes to project and methodical issues. I can be strict about false structures and developments not getting a chance to develop.
  • The competence of the employees makes all the difference!
    I can now look back on more than 30 years of experience in the s-w development sector and time and again I found out that only a fourth or, if you are lucky, a third of the persons working in projects as programmers – no matter what titles or certificates they can show you – can actually deliver top quality. With the remaining two thirds, there might be the potential for some improvement through intense additional education and training programs with half of them. The remainder would have been better advised if they had never chosen to become programmers. In my perception, this relation grew worse, rather than better, during the last few years. That means that many not very well-educated and/or less talented programmers get carried along with the flow in extremely huge projects.
Mind you, this is not because I want to foul-mouth an entire profession. However, what I need in software development are a hundred per cent “top quality” results. And that is something actually only a very small number of programmers working in projects can deliver. When it comes to “architects” or “requirement engineers”, the ratio of truly qualified experts is probably even smaller than with the “implementers” – which makes software development even more doubtful.
Incidentally, it seems to me that other sectors do not differ too much with respect to those numbers.
    For instance, I also noticed that among “craftsmen”, as a general rule, only one third actually are qualified enough in their job to deliver truly top quality products. And this is also an area where roughly one third would have been better advised to choose another career.

    This means that if you constitute a new team, you should only recruit colleagues into the project who actually really know what they are doing. That is true for all roles within the project – and this selection is anything but easy. It is a lot easier said than done – because you have to say “NO” just too often. Regardless of the fact that you really badly need people to work for you. But a compromise in this particular respect will, as a general rule, blow right into your face when it comes to the quality of the results. And if you only take the “good” ones, you will need far fewer …
  • Communication

    The communication within the development team and between all parties concerned with the project must function! How is that supposed to work if in many projects we do not even have a common language? Or if all of the team speak English but every one of them brought his or her “private English version”, which the other party finds hard to understand?
It is important to strictly limit the number of meetings. There must be put a stop to the meeting overflow. Because the actual benefit of meetings will decrease with the number of persons attending and the time they take. To the same extent, the damage will increase. A solution of this dilemma is the organization of communication through a reasonable “peer2peer” mechanism.
  • “Requirement Engineering”

    So far, the attempt at describing application software precisely and completely before its implementation has never rendered optimal results. This procedure will always end up showing that many unnecessary items have been built and, to make up for it, some really necessary items are missing. As a consequence, you get costly change requests that often conflict with the functions to be implemented. In other words: the success of every project depends on the quality of the person or persons who constitute the “product owner”.
High quality product owners will never know everything in advance. Instead, they constantly learn during the development process. An iterative and agile process of “requirement engineering” is an absolute necessity. For new projects, it is advisable to think in terms of “user stories” and then (to a limited extent) describe the corresponding “use cases”. However, this can only work out if the architecture is flexible.
  • “Flexible Architecture”

    Due to the product owners’ learning process and the iteratively changing functionality, an open and resilient architecture becomes a central requirement for the success of the project. This causes higher expectations for the architectures, but also for the communication between the “product owner” and the “architect” and ultimately also the entire team. Incidentally, as I see it, the two last mentioned factors are true for projects in general, not just software projects.
  • Mind-set

    The mind-set has an impact in many dimensions. For instance, all project participants have to pledge themselves towards an ultimate quality requirement from day one. They must understand that, first and foremost, they create quality for themselves. There must be a shared project vision. Cooperation has to take place at eye-level and with everybody respecting everybody else. Politics in the project is a NO-GO! Quality control factors, such as peer2peer reviews will be a matter of course, meetings must be extremely short and far between and if they take place, they absolutely have to be restricted to discussing necessary coordination processes. To make up for it, there is no reason why you should not once in a while celebrate your success.
Unnecessary bureaucracy is another NO-GO, a “good” project culture will make bureaucracy obsolete. The project and its current state are transparent for all parties concerned at all times, “insider knowledge” and “esoteric knowledge” are the exception. Wherever possible, you will dispense with unnecessary efforts for “estimates” and “planning”!
  • Responsibility
    The project participants will never just reduce their own role to one of responsibility. Every one of them must be prepared to work “hands on”. The responsibility for everything – if only for a small fraction of it – is with every individual participant: requirement engineering, project control, architecture, quality, configuration and implementation. Everyone must help reduce unnecessary obstacles against free communication between all the others. This is true for everyone, because every one of them is responsible for the success of the project. Of course, due to the individual qualification, the way how the responsibility is distributed differs.
  • Craftsmanship
    And all parties concerned have to practice their craft all the time. They must be prepared to “learn from the master craftsman” and to “”hand on their special master craftsman competence”, that is to share their knowledge.

If these requirements are met, even small teams can achieve unbelievable things, both with respect to quality and functional quantity. The often unnecessary overhead of big teams does not happen. And eventually, the management will be surprised how a ten-person team could have accomplished something where a team of a hundred failed.

(Translated by EG)

5 Kommentare zu “Ultimative Software Quality!”

  1. Ultimative Qualität für Software | Dieters Blog (Thursday June 5th, 2014)

    […] […]

  2. Software-typ (Monday November 2nd, 2015)

    Full Ack. Ich bin erst 10 Jahre dabei, aber ja, mit 1/4 der Leute (den guten) hätte man zumindest die Chance, etwas gutes aufzubauen.

    Aber Geiz ist geil, daher wird kein Dienstleister mit guten Leuten genommen, weil der kostet 120 statt sich auf 80 Euro drücken zu lassen (pro Stunde). Solche Firmen, und damit auch gute Entwickler, werden einfach nicht nachgefragt/bezahlt, deshalb überlege ich auch, aus der Entwicklung auszusteigen, und mehr in Richtung Anforderungen zu arbeiten, und das, obwohl mir in der Entwicklung keiner etwas vormacht.

    Warum soll man sich aufreiben und kaputtmachen, wenn ein Großteil der eigenen Arbeit darin besteht, die Fehler der Dumpfhirne wieder geradezubiegen? Ergo: wenn man eine Mischung im Projekt hat, canceln die schlechten Entwickler die guten wieder aus. Der schlechte Entwickler sorgt dafür, dass der gute nicht mehr 5x-10x Performance liefert, sondern gerade mal die Fehler eines anderen behebt. Aber hauptsache die Kosten pro Stunde etwas gedrückt! Da haben wir aber fein gespart, was?

  3. Software-typ (Monday November 2nd, 2015)

    Nachtrag: den Status Quo kennen wir ja. Ich glaube, die Ursache ist, dass es tatsächlich zuviele Leute scheinbar billig gibt.

    Software-entwicklung ist viel zu BILLIG, deshalb leisten sich viele ganz miese Zusammenarbeit/Prozesse/Architekturen, geben miesen Entwickler Entscheidungskompetenzen in die Hand – man kann es sich offensichtlich noch leisten.

    Automatisierungsgrad = 0. Wir frickeln einfach mal etwas herum, und nach ein paar Wochen wird alles wieder umgeworfen: der nächste planlose Plan.

  4. Mein Freund, der Softwarebetrüger … | sladisworld (Thursday November 5th, 2015)

    […] Ultimative Qualität für Software! […]

  5. mtx (Friday November 13th, 2015)


    ich bin ja erst gut 20 Jahre dabei, aber aus meiner Praxis-Erfahrung halte ich einen Anteil von 30% guter Leute für enorm überoptimistisch. Realistisch wäre wohl etwa 10%.

    Bei manchen – angeblich besonders professionellen – Dienstleistern sind es eher 0%.

    An der Stelle muß ich mal auf meine Lieblings-Idioten von der ITK einhacken. Viel buntes Papier, große Klappe, aber ansonsten völlig unfähig. Was die abliefern ist einfach nur unbrauchbarer Abfall. Mittlerweile hat das auch meine aktuelle Kundschaft endlich begriffen – jetzt hat man die aus dem (Teil-)Projekt rausgenommen, und alles wird weggeworfen. Besser ein Ende mit Schrecken als ein Schrecken ohne Ende.

Kommentar verfassen