Who has seen the source of many software systems, as I did, knows that most of used software systems are not only defective (i.e. bugged), but highly unmaintainable.
Hordes of gurus explain how to refactor the source code of software systems to improve its maintainability, but this is all useless if the real causes of such unmaintainability is not understood and addressed.
I think that there are at least five causes:
- Time to market. Sometimes a software system is developed with a deadline, that may be a contract signed with the customer, or the simultaneous release of a hardware system, or an important trade fair. If the project is late on schedule, something is to be omitted. Of course internal quality is not as important as external quality to meet the deadline.
- Time to return from investments. To develop a software system is an investment; to sell that software system is the return from that investment; for a given profit, investors want to minimize the time to get it.
- Risk management. Many software systems fail, meaning that they are never really used, for several possible reasons, and therefore there development cost is a net loss. If the system has cost little time, it is a small loss. Instead, if it is successful, it may well be improved later on (but rarely is).
- Developer lock-in. If a developer creates a well-documented, self-tested, and easily-maintained software, he may be replaced by a less expensive developer. If instead his software is so intricate that only he can maintain it in a reasonable time, he may ask for big bucks.
- Unskilled developers. Some developers and some managers don’t know good software engineering techniques and tools.
I don’t know the relative weights of the above reasons, but I think that they depend on the culture, on the kind of software, on the size of software, and on the size of the development team.
For example, where there is a single developer, “developer lock-in” is very important, while it is not so important in a large team.
For a software that is yet to be sold, “risk management” is important, while it is not so important for a project defined by a contract.