To this point, I haven’t linked in any articles on Agile design. This is because I wanted to flesh out my own ideas first before reading what others have to say on the topic. Now that I have a basic model in place, I’d like to compare it to points that others have made regarding design in an Agile environment.
Let’s start out with Martin Fowler’s article, Is Design Dead? Fowler’s focus in this article is Extreme Programming (XP), which I did not emphasize during my series. I’ll admit up-front that I am not a big fan of XP as a development practice, but this is an article full of little bits of insight. Fowler makes a point that I hinted at during my series and would like to emphasize: incremental, evolutionary design works better when you reduce the cost of change. Practices which make it easier to change (such as good test harnesses, clean code, and a dedication to refactoring) also make it easier to re-design.
From here, I’m going to hit a few essays and articles on Agile design, starting with Scott Ambler’s essay of the same name. I give bonus points to Ambler for philosophy #11. I tend to agree with most of his points, although I strongly disagree with his point about database refactoring “work[ing] incredibly well in practice,” but that’s a debate for a different day. When it comes to design, Ambler focuses primarily on story-based design at the micro level, rather than architectural design and higher-level systemic planning. This is important, but when you’re dealing with brownfield applications, I’d say that injecting the occasional “sprint 0 architecture” sprint is important. Ambler’s “sprint 0” is very close to my idea of higher-level design, but this is something that needs to happen more often than just the beginning of a greenfield project. Sometimes, a new “code infrastructure” solves critical problems and makes growth easier even if it does not directly tie to a story on the current sprint.
Another article I found was Luke Clum’s on Understanding Agile Design. Although this is a totally different concept of “design” than what I was looking at—Clum is talking about “design” more in the application look-and-feel sense, whereas I am looking at “design” in the sense of how developers are supposed to build modules and how these modules are supposed to fit into place—it’s an interesting look at another part of the software development problem. Clum advocates pushing designs to customers as early and frequently as possible, which sounds like a good idea when talking about his definition of design. I want to jump back to my definition and point out that pushing out production code early can lead to a big problem: design lock-in. You start off with the prototype, but now people are counting on this application, so instead of throwing away the prototype and starting fresh with a sturdier foundation, you have to spend more and more time patching the prototype.