The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Iterative vs Waterfall DB Development

NOTE: I made a mistake by submitting this post on the "Business of Software" wiki. I couldn't find a way to delete. Oops.

I believe that my development approach leans towards iterative database development. I acknowledge the need to have an open attitude when it comes to change. What happens when you work with others that believe that you need the majority of your database requirements up front? I am interested in hearing other opinions on iterative or waterfall database development. Even if waterfall is the project method, I would imagine that change management would have to play a role in the dev life cycle.

When I get into the debate between iterative vs waterfall type development, I try to approach it by saying that I see the waterfall method having merits, but that iterative development can be used as a complement. I believe that methods don't need to be mutually exclusive. Anyways, it can get frustrating because my colleague has the "my way, or the highway" attitude.

Are there others that can share similar experiences?

Wednesday, June 18, 2008
Don't get caught up in these arguments.

Wednesday, June 18, 2008
Wednesday, June 18, 2008
Those methods are NOT complementary, by definition.
Wiki is your friend
Thursday, June 19, 2008
> frustrating because my colleague has the "my way, or the highway" attitude.

Unless colleague has the "highway" power it really isn't up to him is it.  Shouldn't something as important as your entire development methodology be set by a team lead/project management?
Thursday, June 19, 2008
IMHO, "Iterative -vs- waterfall" determines how fast your product can be out to market and what state of usability (i.e. debuggedness) your software app is when users start using it. But all this can be reduced if you already have a good and well-qualified development team in place.
Thursday, June 19, 2008
Thank you, sgf, for reminding me about that site.  I have sent an E-mail to my software engineering instructor of last fall suggesting that he might find it of use.  He has a wicked sense of humour.

One of the assignments that he gave us was meant to be nearly impossible.  I caught on right away to the difficulty of the assignment and called him.  He told me that it was to make the point that some problems are not technical problems.

Next class, he let the cat out of the bag.  He then gave another assignment and said we could work on whichever one of two we wanted.  Two teams still went for the first assignment.


Gene Wirchenko
Gene Wirchenko Send private email
Monday, June 23, 2008
I prefer the Iterative approach but do believe there needs to be some upfront work to at least get 70% of the requirements. 

The reason for this is that if you're building something, let's say a car, you wouldn't first design each piece individually without seeing if it's going to work for the entire car.  Otherwise, it may end up being an SUV when you were looking for a sports car.

But with the iterative approach, if you can at least design a fuzzy model over all, you can then fine tune it later iteratively.

Ultimately, you cannot design a complete system upfront because most people cannot visualize a product until they can actually see it in front of them.  So, whatever requirements you get up front will change just because the users didn't realize what they were asking for.  That's why the iterative approach works so well.

Plus the nice thing about iterative development is that it keeps users intimately involved.  There's less likelihood about arguing about change orders just because they understand each step much better.
Dan Sionov Send private email
Monday, June 23, 2008
I normally prefer the iteretive approach.
(To the extent of coding up php prototypes and changing them during discusions with hte users!).

However data models are one of the few areas where a lot of up front design really pays off.

While its relatively easy to change from checkboxes to pulldowns in a GUI or change the presentation of a list, refactoring a change in the underlying data model is hard; a single datamodel change can result in changes to all your programs and sometimes a change in the way the programs are structured.

A change from a one to many to a many to many relationship will almost certainly result in a change in the presentation layer in terms of screen flow widgets etc;
Wednesday, June 25, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz