Software developers write software. That is certainly true on first sight, but on a second look there are more forces at work. Many software projects take on a dynamic of their own and that is not always a good one. Especially open source software, which is only partially bound the strangling restrictions of budget, tends to become driven by team dynamics, rather than user needs. Consider the following lifecycle:
- Some software projects have trouble lifting off. Often they are started by an enthousiast who writes it on his own and occasionally gets token support from others. Frequently the scope of the software project is too wide, or the creator has not enough time and willpower to go on. Such software tends to reach version numbers like 0.2.6 beta and then sit idle for a few years before disappearing into oblivion.
- But a few competent developers do succeed and reach version 1.0. If the software excels in usefuleness or usability (two very different things!), it gets noticed be others and because somewhat famous. Other programmers may join in and a whole community may form up around the software, which can become famous in a limited group.
- If software becomes popular, more and more users join in, requesting different features, styles and platform support. The work becomes too much for a single developer, but a team can manage it. New versions are released, ever richer in functionality and scope. Bugs are fixed quickly and after some time the thing has become really good. Such software can attain world-wide popularity and fame.
- After a time software, when supported by a competent developer team, will reach maturity. This means that is essentially finished; all required features and platform support are available, all but the most obscure bugs fixed, etc. The only things that are required from that point onwards are infrequent updates for new protocols, platforms and the like - essentially all maintenance tasks, which require relatively little effort.
- But by that time most software projects have a large number of developers who do not want to sit idle. So they start invent new things: extra features, radical redesigns of the user interface, etc. These things are not necessary, but the limits of necessity have become blurred. Now a strange thing happens: the software stops getting better; often it becomes worse. As a result, users are abandoning ship and switching to competing software.
Should you be a software developer who has worked in teams with their own dynamic, you may recognize the line of events described above. There is a saying in software development: If you know where the problem is, you are half-way to solve it. I urge software developers to not only develop software, but also reflect on its use. If it is finished, it is finished. Switch a minor part of your efforts to maintenance; devote the major part to something new.