Connecting the Dots Between Analysis and Design
Filed Under Software ProcessMost software teams seem to lump together the terms Analysis and Design into one pre-development phase. This is unfortunate because with enough effort in first determining what you wish to build (aka Analysis) it is possible to understand the domain enough not to need up front architecture (aka Design).
I find this much like a children’s connect-the-dots puzzle. For example, if each user story (or requirement) is flushed out ahead of time, it might be possible to view and understand the entire domain without connecting any lines.
Understandably, it may not be possible to completely comprehend the domain solely on user stories. In essence, the definition of design or prototyping – connecting the minimum number of dots together to understand the full picture.
Determining what needs to be built is the hardest part of development. Now that the development team has a shared vision of what needs to be accomplished, they can fill in the implementation with relative ease.
This process, while simple, still takes a lot of maturity to accomplish. Some pre-develoment teams attempt to solve the entire puzzle at the same time of gathering the requirements. Attempting to solve a larger puzzle with only a subset of the information is only an exercise at best. Lack of information, misinformation, and unorganized information may all start leading your team to start drawing pictures of the domain that do not represent the true domain.
Do not fall prey to Analysis Paralysis; sometimes good enough has to be good enough. Equally as dangerous is false starting by assuming that you have enough information to act upon. Remember that being agile does not shield you from prematurely drawing a picture of a horse’s ass instead of an elephant.
6 Responses to “Connecting the Dots Between Analysis and Design”
Ah, the classic children’s connect-the-dot analogy. Brilliant. It not only provides an accurate depiction of BDUF vs correct agile vs premature agilization, but it also gives us great insight into what kind of hobbies you engage in during your free time…:-)
Hi there.
I just found your blog.
I like it 🙂
Separation of finding out what the problem is and trying to solve the problem always seems to be a difficult line for technology folks to see.
According to Men are from Mars Women are from Venus it is a man issue altogether (www.marsvenus.com).
But with that said this is where I think an experienced software developer, project manager, or business analyst really earn their money as we have already made those mistakes or learned from others who have.
As experienced professionals we need to push back on the madness that force projects into a corner where the only possible outcome is failure. In my consulting jobs I notice way to many times when totally irrational behavior is not only accepted but often promoted! The question begs to be asked, how much further would we be ahead if we valued experience by LISTENING to it?
Links from the Sharpside [10.29.07]
Links from the Sharpside [10.29.07]
Design is not architecture. This blog is full of fail.
Kindly share if any more datum is there ???