Agile, Emergence and Deliberate Design
Emergence is good, but…
…it takes time, and
…under some circumstances it may not happen!
If you have been there … done that … then you don’t have to wait for your application architecture to emerge over several iterations. You can use your past experience to nail it down at the beginning.
However, if all the team members are new to the problem or the technology – experimentation, trail and error would be need to arrive at the design and architecture.
Alternately, the team can take the help of a specialist who can get them going. This can cut down lot of exploration into blind alley. You may feel that it is be better to learn the hard way but imagine if we had to learn everything by ourselves from scratch – you may have to start by inventing the wheel!
So, a good question to ask is…
…where do you draw the line between the allowing the design to emerge and doing an upfront and deliberate design?
…to what detail should go?
…how much of external help should you take?
Related Articles
Comments
4 Responses to “Agile, Emergence and Deliberate Design”Trackbacks
Check out what others are saying...-
[…] Agile, Emergence and Deliberate Design […]
-
[…] Agile, Emergence and Deliberate Design Share this:LinkedInTwitterFacebookStumbleUponPinterestEmailLike this:LikeBe the first to like this. […]
Technology Trend Analysis 
The key is differentiating between Big Up-Front Design and No Up-Front Design. While the former is generally to be avoided, the latter will likely cost you in wasted time and rework. An evolving architecture that results from considering the needs at hand plus those most likely to follow will be more flexible than “the simplest thing that could possibly work” that needs to be reworked with each sprint/iteration/release. BUFD is a form of micromanagement and NUFD is an abdication of any attempt to plan. As with most things architectural, somewhere in between is generally your best best.
something like a divine intervention?