Software development is more than engineering and still needs the human factor to be successful, says Federico Carminati.
I have led software projects since 1987 and have never known one, including my own, that was not in a crisis. After thinking and reading about it and after much discussion I have become convinced that most of us write software each day for a number of reasons but without ever penetrating its innermost nature.
A software project is primarily a programming effort, and this is done with a programming language. Now this is already an oxymoron. Programming is writing before; it entails predicting or dictating the behaviour of something or someone. A language, on the other hand, is the vehicle of communication that in some ways carries its own negation because it is a way of expressing concepts that are inevitably reinterpreted at the receiver’s end. How many times have you raged “Why does this stupid computer do what I tell it [or him or her according to your momentary mood toward one of the genders], and not what I want!?” A language is in fact a set of tools that have been developed through evolution not to “program” but to “interact”.
Moreover every programmer has his own “language” beyond the “programming language”. Many times on opening a program file and looking at the code, I have been able to recognize the author at once and feel sympathy (“Oh, this is my old pal…”) or its opposite (“Here he goes again with his distorted mind…”), as if opening a letter.
Now if only it were that simple. If several people are working on a project, you not only have to develop the program for the project but you also have to manage communication between its members and its customers via human and programming language.
This is where our friends the engineers say to us “Why don’t you build it like a bridge?” However, software engineering is one more oxymoron cast upon us. We could never build software like a bridge, no more than engineers could ever remove an obsolete bridge with a stroke of a key without leaving tons of scrap metal behind. Software engineering’s dream of “employing solid engineering processes on software development” is more a definition than a real target. We all know exactly why it has little chance of working in this way, but we cannot put it into words when we have coffee with our engineer friends. Again, language leaves us wanting.
Attempts to apply engineering to software have filled books with explanations of why it did not work and of how to do it right, which means that a solution is not at hand. The elements for success are known: planning, user-developer interaction, communication, and communication again. The problem is how to combine them into a winning strategy.
Then along came Linux and the open source community. Can an operating system be built without buying the land, building the offices, hiring hundreds of programmers and making a master plan for which there is no printer large enough? Can a few people in a garage outwit, outperform and eventually out-market the big ones? Obviously the answer is yes, and this is why Linux, “the glorified video game” to quote a colleague of mine, has carried a subversive message. I think we have not yet drawn all the lessons. I still hear survivors from recent software wrecks say: “If only we had been more disciplined in following The Plan…”
Is software engineering catching up? Agile technologies put the planning activity at the core of the process while minimizing the importance of “The Plan”, and emphasize the communication between developers and customers.
Have the “rules of the garage” finally been written? Not quite. Open source goes far beyond agile technologies by successfully bonding people who are collaborating on a single large project into a distributed community that communicates essentially by e-mail. Is constraining the communication to one single channel part of the secret? Maybe. What is certain is that in open source the market forces are left to act, and new features emerge and evolve in a Darwinian environment where the fittest survives. But this alone would not be enough for a successful software project.
A good idea that has not matured enough can be burned forever if it is exposed too early to the customers. Here judicious planning is necessary, and the determination and vision of the developer is still a factor in deciding when and how to inject his “creature” into the game. I am afraid (or rather I should say delighted) we are not close to seeing the human factor disappear from software development.
