This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: What is Good Software Design?
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
James Shore writes about good and great software design in an article titled Quality with a Name. From the article:
A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.
From this definition, he goes on to consider various design principles, but winds up in an interesting place that I’ve often found myself visiting:
Every design decision is made in the context of the whole design. The problem being solved; the other design decisions that have been made; the time schedule; the available pool of programming talent; etc., etc.
Context makes every piece of specific design advice suspect. I'm not saying that you shouldn't listen to it... you should! But at every moment, you should ask yourself: "When is this not true? What is the author assuming?"
I am constantly reminded of the role of context in almost every software “best practice” or “pattern”. As engineers, we are driven to simplify, codify, and categorize eveything we do so that it can be reused, leveraged, or repeated with a near-guarantee of success.
Context works against us at evey turn. It takes a universal “truths” and makes them into horrible errors of judgement. Or at least opportunities to blame someone else.
The message is clear: applying best practices and universal truths is no substitute for thinking. An engaged and informed brain can run circles around a mindless implementation of what “they” say works. Not that “they” don’t have something to offer, but it always comes in a wrapper of context.
Previous Topic
