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.


Popular posts from this blog

Custom built SBCL and using spaCy and TensorFlow in Common Lisp

I have tried to take advantage of extra time during the COVID-19 pandemic

GANs and other deep learning models for cooking recipes