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.
RMD
(Translated by EG)
Loading ...