Design up-front vs. along-the-way
I had a discussion at lunch yesterday about the right way to do design.
Waaaaaay back when I was in school - when Van Halen's "Jump" was at the top of the charts - we were introduced to the Waterfall Model of software development. (aside - it Royce's model was iterative, but it was rarely discussed that way - the typical discussion broke the whole project down into phases).
Anyway, the waterfall model (and some other models as well) have distinct phases. In waterfall, you first collect requirements, then you design, then you implement, etc.
I've never found that to be very workable. As Field Marshal Helmuth von Moltke said, "No plan survives contact with the enemy" (actually, what he said was, "No operation plan extends with any certainty beyond the first encounter with the main body of the enemy" (though he likely said something like "Kein Betrieb Plan verlängert mit jeder möglicher Sicherheit über dem ersten Treffen mit dem Hauptkörper des Feindes hinaus" (or at least that's what he would have said if he spoke English and used Babelfish...)))
That doesn't mean that you should have a design, it just means that you should expect your design to change along the way as you learn more. But without spending time on design, you are likely to make some errors of architecture that will be difficult or costly to fix.
And just going off and starting coding would not have been tolerated by Tony Jongejan, my high school programming teacher.
At least that's what I used to think. These days, I'm not so sure, for most applications (see caveats later).
The problem is that, unless you've already built such a program (some of which is codified in the prototyping and "build one to throw away" schools of thought), you rarely have enough information to make informed choices, and you won't have that data until you actually write the code.
I think that you're far better off if you focus on building clean and well-architected (at the class level) code that has good unit tests, so that you'll have the ability to adapt as you learn more. It's all about the resiliency of the source to the change that is going to come, and letting the code evolve to do what it needs to do.
Caveats? Well, there are a few.
If you're in the library business, you will at some point have to put a stake in the ground and ship the thing, which will severely constrain further modifications. Your library may also be used in ways you didn't imagine.
I think the right way to solve that is with a little design up front, a lot of prototype use, and then a good review process before you ship it.
So what do you think? What amount of design is right before coding?
Comments
Anonymous
December 01, 2004
Step back from the design and see what drives that....most often it is the lack of proper requirements that leads to an incomplete design. The team then has to augment the design as requirements become clearer. That means that it's a constant challenge to keep the original elegance of the design intact and add more and more pieces to it. So bottomline is, try as best as possible to nail down the requirements.
Second thing useful, but very very unconventional . Have you ever thought of writing a test app for an app that you haven't written yet? Think about it this way. When you sit down to write the test application, it forces you to think what your target application does. It forces you to think what you are going to test and that means if there are areas you didn't seriously consider, these might come to mind. Secondly, again, it drives the requirements of the target application which helps you achieve clearer .
Somehow I'm getting the feeling I have severely digressed from the original post. Forgive me please if that is the case! :-)Anonymous
December 01, 2004
The comment has been removedAnonymous
December 01, 2004
I believe that in order to create a very polished user-oriented product constant feedback is needed in the process. The best process for this type of development needs to accept a certain amount of hand-waving; development and the designers need to agree upon what the limits of change are ahead of time. Great architectures should embrace change, the fact of development is that requirements change. I have yet to encounter a designer who was able to create flawless specs that never changed, the inability to deal with these yields bad products.Anonymous
December 01, 2004
Ive never found the upfront design process to be entirely viable. Its often the case that the client/user is unable or unwilling to get involved at the design phase, and then becomes more involved after something usable is put into their hands.
The key is to put something into the clients hands as early as possible, and that something should be both usefull in that it fulfills some of the clients needs, and it should also act as a starting point for further discussion about what its future is, i.e. it should engage the clients imagination.
Ive never found the prototype and throw it away approach to work in the real world. Firstly, no-one understands why you want to throw all your hard work away, and secondly, if your prototype is succesfull by any measure, people will just start using it.
What seems to have worked well on my latest project is a plug-in architecture. A single app within which cooperating plug-ins live, much like the eclipse rich client platform. Clients sense the potential for growth, and that growth can combine increments of addition and revision without too much pain.
A previous posted suggested that an incremental approach isnt suitable for pacemakers, and thats celarly true. However, the requirements for a pacemaker are relatively simple; at least, they can be known ahead of time. For something like a nuclear power station, I would hazard a guess that there is an underlying iterative process going on, even if a waterfall process is prescribed.
Theres a really good book about this that I read a while back. Its called "The Blind Men and the Elephant: Mastering Project Work" and is subtitled "Producing Meaningfull Results from Fuzzy Responsibilities" - its by David Schmaltz
http://www.amazon.com/exec/obidos/tg/detail/-/1576752534/103-4314954-3537466?v=glanceAnonymous
December 01, 2004
Since I just turned 0x028 years old, I remember when Jump was at the top of the charts.
I've never found any one model to be the end all of programming. Generally, I get as many requirements as I can, design off of that, code (including unit tests), go back and change the design, code more, test, change the design, code, and test. Multiple times in the cycle the requirements are modified, and the design and code reflect that.
For the past lot of years, I've worked on a project that gets vague requirements from multiple external sources. We design, code, test, and release in the space of four weeks. After the release, some requirements are updated or clarified, new ones are added, and the cycle starts all over again. For this, a well-architected app is key.Anonymous
December 01, 2004
The comment has been removedAnonymous
December 01, 2004
First, to resonate with a couple of previous posts, no matter how you try to put it, the iterative nature of the process is unavoidable. Absense of iterations implies attainability of perfection, and we all know that's impossible. Whichever great deed you set out to do, you WILL have iterations. The only difference is whether the circles of iterations touch the end customer and how close do you want or able to get to the said perfection. In the case of pacemakers, believe me, there are countless prototypes, test cases and "back-to-the-drawing-boards", with only the final circle resulting in product acceptance.
The waterfall model is not a flawed process. It's simply a naive, cropped view of the iterative process. Forgetting that the boomerang circles back around almost always results in a painful experience.
Unfortunately, the neat circle (or "nautilus" spiral, depending on who you read) of the iterative process is also misleading: in reality, there are multiple circles, nested and sometimes overlapping, as small as individual code unit cycles and as large as company's continual refinement of strategic direction (buddhists would go even further and fit all of them into the wheel of life :).
Thus, the complexity of process management (project management) is not in realizing its iterative nature, but in creating an accurate (features) and realistic (money) vision of the process and how it fits into the larger picture (customer). Software development is trivial within the process that's well formulated and understood by all participants.Anonymous
December 01, 2004
The comment has been removedAnonymous
December 01, 2004
I don't believe in the grand up-front design. I have yet to see it work. But I do believe in a simple plan and small mini-design sessions just before I code.
When the requirements change, the plan change, and so does the code. What I discover all the time, is how easier it is to change well-refactored code.
So I guess it pays to gold-plate just a little, but only where you need it.Anonymous
December 01, 2004
In response to the design of pacemakers and nuclear missiles.
Unit testing is only half the equation, you still need comprehensive acceptance tests. Rather than have comprehensive requirements I think for these systems you need to have comprehensive acceptance tests, which are really just requirements expressed in automated tests. You can still incremently develop the design. What you want to do is spend a lot more time validating the end product. see http://www.testing.com/ which discusses how to do good testing using agile techniquesAnonymous
December 02, 2004
The comment has been removedAnonymous
December 02, 2004
The comment has been removedAnonymous
December 03, 2004
The comment has been removedAnonymous
December 03, 2004
I get so frustrated with people who whip out the building analogy.
Yeah, constructing software is like constructing a building. If you were putting it on Jupiter. And constructing it with entirely alien materials and tools.
Architects and construction workers have the luxury of working within the laws of physics. Software developers don't. We work within the constraints of "some other guy's idea of how things should work", which is considerably less.. reliable.Anonymous
December 03, 2004
The comment has been removedAnonymous
December 03, 2004
The comment has been removedAnonymous
December 04, 2004
Steinar: Try to live in a software and you will get it :)
BTW, building is actually done with F7, ctrl-shift-B, make, or something similar, not with install. See http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm
A great article.Anonymous
December 05, 2004
Radu: I do of course know that in software-terminology building is the process of compiling the source to program files. :-)
My point however is that the process of creating software can’t be mapped one to one to creating buildings. When building a house you are in a way just ‘installing’ the blueprint. It’s creating the blueprints that is the complex job. – The job of the architect. :-)Anonymous
December 05, 2004
Steinar: Of course I knew that you knew :) It was partly a joke and partly an attempt to point out that "to build" is often used in software.. and the choice of words is not completely haphazard.Anonymous
December 06, 2004
As somebody who designs, develops AND consumes my own financial derivatives software, my own experience is that it's impossible to specify stringent requirements up front. The customers (myself plus others) are constantly evolving the requirements as their business environment changes. I guess that's really my main finding from my own experiences: that the underlying business logic for many parts of an application tends to evolve randomly as time progresses.
For me, architecture choices tend to be made so that I commit the minimum amount of lock-in to the current business logic and architecture. Codebases just don't last 20 years.Anonymous
December 06, 2004
The comment has been removedAnonymous
December 10, 2004
Two different tools for two different problems.
Sometimes the requirements are sufficiently knowable that you can use big-design-up-front approach successfully. If you truly know the requirements, BDUF works really well (been there, done that, loved it).
Sometimes the true requirements will not be known, can not be known, until very near (or after) the customer gets the product. In that case, BDUF is a waste of time (been there for a month, not loving it at all).
It can be very hard to know whether you truly understand the requirements though - "understand" in the sense that what you think you need to create really is what the end user wants.
My favorite quote ever: "It's just what I asked for, but it's not what I want."Anonymous
May 26, 2009
PingBack from http://backyardshed.info/story.php?title=eric-gunnerson-s-c-compendium-design-up-front-vs-along-the-wayAnonymous
May 29, 2009
PingBack from http://paidsurveyshub.info/story.php?title=eric-gunnerson-s-c-compendium-design-up-front-vs-along-the-wayAnonymous
June 08, 2009
PingBack from http://jointpainreliefs.info/story.php?id=57Anonymous
June 12, 2009
PingBack from http://weakbladder.info/story.php?id=5834Anonymous
June 15, 2009
PingBack from http://debtsolutionsnow.info/story.php?id=10175