I’ve been looking back at software projects that I either developed or managed. I thought about which projects produced software that is actively used and which didn’t. Here’s what the popular projects had in common. The software
- was developed to address existing needs, not speculation of future needs;
- solved a general problem; and
- was simple, often controversially simple.
The software used most often is a numerical library. It addresses general problems, but at the same time it is specialized to our unique needs. It has some functions you won’t find in other libraries, and it lacks some functions you’d expect to see but that we haven’t needed.
A couple of the more successful projects were re-writes of existing software that deleted maybe 90% of the original functionality. The remaining 10% was made easier to use and was tested thoroughly. No one missed the deleted functionality in one project. In the other, users requested that we add back 1% of the functionality we had deleted.
Right you are on simplicity. From my perspective, it’s the simplicity of the user interface, but it could be the simplicity of a software API, etc.
It would probably do us all some good to review our projects and their successes or failures. In my case, complexity is generally the doom of my software: too many choices, too many non-users having a hand in specifying functionality…
Amen. I call this “iterative programming.”
Iteration 1: solve the immediate problem in enough generality that it can be reused, if required.
Iteration k for k>1: When a new request come in, see iteration k-1.