The Middle Path

I have been involved with a few projects that were either way over designed or not designed well enough. The middle path is almost always the best. It is a good idea to look at software development as a cost and evaluating the utility of steps in the development process by how much they cost vs. immediate and long term benefits.

I once came into a project where a half dozen people had been using CASE tools to design a large system for almost a year. I was impressed until I asked to see a demo of the system that they were developing - there was no software written (to speak of) almost one year into the project. Oops.

I think that we have all experienced projects that errored on the opposite end of the spectrum: small under designed projects that evolved into expensive to maintain large projects.

I think that design artifacts should "pay their own way". If a dozen use cases written on 3x5 cards, a few activity, sequence, and perhaps really high level class diagrams are adequate, why do more? It is great when design artifacts can be kept in CVS along with code. Plain text and diagrams in a portable text based format are best. It is not so easy to do, but it is best when designs and the software evolve together over time. It is fine to refactor code - it is also fine to refactor designs.

Comments

Popular posts from this blog

Ruby Sinatra web apps with background work threads

My Dad's work with Robert Oppenheimer and Edward Teller

Time and Attention Fragmentation in Our Digital Lives