ContinuousDesign

http://groups.yahoo.com/group/testdrivendevelopment/message/156

"Indeed, we have taken to experimenting with different "memes" for the XP practices with different people to combat the sometimes "extreme" reactions we get when dealing with many of the folks we encounter in our (largely conservative, blue chip) clients. For example, we say "continuous design" instead of no BDUF. We describe the Planning game as "parallel analysis". Perhaps because we are Canadian :-} we have found that toning down the extreme rhetoric has helped in acceptance of the process at our clients. Be sure that we still adhere to the practices -- we just talk about them differently."

I think ContinuousDesign is a good antonym for BigDesignUpFront (better than DesignAsYouGo). --PaulChisholm

I like it. It's like StructuredProgramming. Nobody's going to say ContinuousDesign is a bad idea, or they'd be promoting discontinuous design, which sounds dumb.

---

The reluctance of agile methods to do BigDesignUpFront has led some to say, "See, they say they don't do design!"

 Clearly false; but what do agile practitioners do instead?

---

Design As You Go : A phrase that's appeared in a few articles on XP. That sounds right - a little design here, a little design there, some design decisions made during unit test construction, some made during coding - and sounds as if it could be an appropriate antonym to BigDesignUpFront. (Later: A quick Google Groups search of Newnews suggests "design as you go" is used as a pejorative, as a synonym for "no design," by XP opponents. Not encouraging. Perhaps "real design as you go"? Hmmm)

There's still one unnamed distinction. BigDesignUpFront results in a big design artifact (VictorianNovel). ContinuousDesign does not usually involve lots of little incremental change to some design artifact(s). AlistairCockburn has said (I believe) that scaling up organization size requires additional artifacts for communications. I don't know how that's addressed by ContinuousDesign (or the various agile methods). For small enough groups, including most or all that have practiced ExtremeProgramming, it appears to be possible to use the unit tests and source code as sufficient design artifacts. -- PaulChisholm

Good catch. Perhaps the generation of artifacts is handled with ScottAmbler's AgileModeling. I'm not that familiar with it. PleaseComment.

Likely because BigDesignUpFront is given as the only alternative to XP style ContinuousDesign. This not the case. It's quite possible to create a strategy, fill out the tactical positions, and the execute the implementation without resorting to BigDesign or LittleDesign.

---

Pulling one out of my magical BuzzWord hat -- how about JustInTimeDesign? Marketing-types ought to go ape over that one. [After noticing the page already existed: Damn, looks like someone beat me to it by a few years...]

---

I stumbled across the phrase ContinuousDesign and like it better than my previous suggestion (DesignAsYouGo). I'm tempted to refactor that whole discussion over there. Maybe later. --PaulChisholm (later: thanks to whoever did this!)

---

I'm fairly new to this Extreme stuff; but what I've seen seems to coincide with my thoughts from the first time I read about refactoring. If refactoring becomes simpler than up-front design, then design becomes a burden. -- DaveWhipp

---

I wrote a paper on ContinuousDesign which was published in IEEE Software. It's available on MartinFowler's website at http://www.martinfowler.com/ieeeSoftware/continuousDesign.pdf. I was looking for an alternative to "evolutionary design" and "emergent design" and settled on Continual Design. At the last moment before publication, I changed it to Continuous Design. Later, I discovered this page... happy coincidence. It makes me think "continuous design" is a good name for what we do. --JimShore

My old English teacher would have been proud of you, for you would have discriminated finely (or "nicely" as he might have said, with a wry grin) between the two words. He would admonish you to beware, however: since the distinction is a subtle one that is lost upon most people, one should avoid relying upon it. I'm tempted to aver that he would have preferred the term IncrementalDesign: less accurate, perhaps, than AmeliorativeDesign, but far more accessible.

---

see AgileModeling, TestDrivenAnalysisAndDesign, DesignAsYouGo

---

CategoryPlanning CategoryAnalysis CategoryTime