Why does good software take so long to build?
I’ve been growing a new program. It could be a CAD program, it could be a project management program, it might be an idea facilitator. Actually its all of this and more. It’s hard to put a label on it, because we’ve spent seven years thinking about how people work with CAD designs, and why CAD is so useless for that initial Eureka! moment and it’s “napkin-space” expression.
Categorizing a program is easy if it’s just another “me-to”. We all know and agree what it does. But if we go off into the wilderness and explore what kind of tools would be really useful, the result may not fit into existing categories. New thinking may yield new categories, and it usually takes more than one of something to see what about it makes it a category.
Joel Spolsky has written an excellent article on the time good projects take, Good Software Takes Ten Years. Get Used To It. He talks in his blog about the Chandler project, and how it has taken seven years so far. The observation that good software takes a long time has many examples – and the best ones always seem to involve innovative programs that really focus on user interaction and how users think about their work.
One of the most influential books I’ve ever read is Fredrick P. Brooks “The Mythical Man-Month”. While this book discusses the design and implementation of OS-360 back in the days of punch cards, it remains relevant today because it is much more about the nature and costs of communication within a design team. For over 25 years, I’ve asked every new employee of my company to read this book. The 20th-anniversary edition has four additional chapters, including the article, No Silver Bullet, which has inspired a lot of commentary. The book also includes his own re-evaluation of that article, discussing the prospects he sees for improvements in productivity.
After first reading the book, I decided to change how I went about making programs. I adopted an evolutionary approach of growing a program around a central skeleton. With this approach we always had a working program. We then mixed that with an engineer’s negative feedback loop: send copies to real-life clients and have them try to use it. Listen with an open mind, suppressing one’s conceptual immune system, and adapt the program. Repeat in as tight a cycle as possible.
Originally, sending floppy disks around the world resulted in a two or three week feedback loop. Things really took off with the internet, when we began almost-daily decision loops. To this day, this ability is what I most value about the internet – I can actively involve our clients in the design of the tools we are making.
Chapter 17, “”No Silver Bullet” Refired”, touches on this methodology. I’ve been using it for almost 30 years now, and it has enabled a very small team to make several generations of CAD programs that have satisfied our customer’s needs. One result of designing a program in this manner is that it requires radically less support – a major cost of a software product – since it was by the nature of the process designed to work the way our clients think about their work.
This entry (Permalink) was posted
on Thursday, October 1st, 2009 at 5:45 pm and is filed under Uncategorized.
You can follow any responses to this entry through the RSS 2.0
feed.
Both comments and pings are currently closed.