Software Lifecycle Planning Methodologies

I’m learning how industrial software development has changed in recent years. My entire focus up until recently has been from a developer’s perspective. Now I’m being forced to look at the business issues surrounding how you price a large product development effort that has a moderately small software component (small in terms of the total value of the contract, that is).

It makes me shudder a little bit. Primarily because we could do so much better but it would take a revolutionary change in business practices instead of an evolutionary change. I’m not saying that these practices won’t eventually evolve to better reflect the experience of software developers. I’m just saying that there will be some large lag (10 years or so maybe) between the time we discover a software planning  methodology and the time it is reflected in business practices.

It also brings home the point that large businesses are inherently inefficient. The best software is almost always written by a single person that has been able to get their mind completely around a problem and its solution. People can help the author realize their vision but seldom do you find more than one person that really gets the total picture of a product. The solution to this problem is “lots of pieces, loosely coupled”, each one developed independently. If you can rigorously specify the functionality and interfaces of a piece of software, you have created an abstraction that can be used as a building block to achieve more complex behaviors.

Now you know the hackers’ biggest secret, study the interface, not the code. If you have to study the code, you’re doomed. Well maybe not doomed, but set back months or maybe even years.