|
Reviewing the entire design before you code corresponds to the earlier stages in the waterfall model of software development. Case studies and papers (e.g. Harvard/MIT Sloan reviews) have shown that following the waterfall model generally doesn't create a good software product that is useful to the customer. This is because the customer doesn't actually know themselves what they want and only have a general idea of how they would like the software to work.
No matter how much time you spend designing, there will always be something missing or wrong with the current design which would handicap the software. To create something that will actually be useful to the client, you have to be able to allow some changes to be made without having to resort to tons of rescheduling everytime a suggestion for a new feature is made (unless it's a feature that requires too much redesign).
That's why nowadays most managers and software shops have shifted to a paradigm in which changes are embraced via a software devlopment process that isn't as structured as the waterfall model. Many of them have found that new software methodologies such as XP (Extreme) Programming and Agile Development allows them to create software that meets the clients needs better. Most of the core concepts in these new methodologies emphasize less up front design and more rapid prototyping to enable the customer and the developer to see design flaws earlier and more quicker. Only partial designs and documentation are created such that they are sufficent enough to quickly create the product (or prototype). A lot of the code is usually throw away code, but that is expected with the newer methodologies and is okay since a better design and a more useful feature set evolves via the process.
If the customer only gets to see most of the feature set interoperate after months of design and development, and after seeing it decides that the previously designed features wasn't really what they wanted then you've just wasted your own as well as the client's time.
|
|
|
|
|
That is why you break projects into phases. Building section by section with an eye on each section to fit into the next section. At any time you can take a different path just by chaning the next phase, which has not had months of code work put into it.
The problem with XP and Agile Development is you find one project seriously compromises and takes over a small company. You end up prototyping till you are blue in the face and every one in the company gets involved, whether they should be or not. You waste both your time and the clients time with meetings where you sit and show them the new prototypes.
If you take london for example where it takes at least an hour to get to a meeting and then an hour to get back to the office, then prototyping becomes innifecient and time consuming. You rapidly find yourself at the end of the "analysis and design" phase with just some slapped together code, no agreements and a zillion more ideas. That is also a big problem with XP. Design agencies have found this out long ago. If you present a client with a bunch of options they start to get side tracked, coming up with all sorts of other things, instead of focusing on the project.
Also believe me, I like prototyping, but when a client sees a prototype website which looks quite good and was created in two days, no amount of explanation will make them believe that the full website will take two months. They don't get that a prototype is slapped together, like a house made of string and tin foil and that a proper "house" will take much longer to build. They think you are ripping them off and bad blood enters the relationship.
We have tried everything and find that rigid but small phases work best. Component by component, with sign off and around-the-board agreement.
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge
Martin Marvinski wrote:
Unfortunatly Deep Throat isn't my cup of tea
Do you Sonork? I do! 100.9903 Stormfront
|
|
|
|
|
Paul Watson wrote:
That is why you break projects into phases. Building section by section with an eye on each section to fit into the next section. At any time you can take a different path just by chaning the next phase, which has not had months of code work put into it.
The problem with this is that the client doesn't get to see all of the major features interoperate with each other. Building the system in stages only allows the user to see the already developed stages working together. What happens when you've finished developing the next stage, shows it to the client, and the client finds out that the newly completed module works great but invalidates their idea of the way the previous modules should work? Then you would have to redo the previous components. It would be far more beneficial to allow the client to see almost everything the client wants in a prototype first.
Paul Watson wrote:
The problem with XP and Agile Development is you find one project seriously compromises and takes over a small company. You end up prototyping till you are blue in the face and every one in the company gets involved, whether they should be or not. You waste both your time and the clients time with meetings where you sit and show them the new prototypes.
More time does need to be invested in using these methodologies, but it's time well spent. People should be emphasized over processes. Going to a corner and coding for a few weeks after receiving the signed off specs and then returning with the code does involve less meetings. But the client doesn't get to see the module gradually grow and thereby doesn't have a chance to let the developers know that the current module won't be adequate enough for what they want to do. Stopping development and correcting the design early before anymore coding takes place saves more time and frustration over the time saved by less meetings.
Paul Watson wrote:
If you take london for example where it takes at least an hour to get to a meeting and then an hour to get back to the office, then prototyping becomes innifecient and time consuming. You rapidly find yourself at the end of the "analysis and design" phase with just some slapped together code, no agreements and a zillion more ideas. That is also a big problem with XP. Design agencies have found this out long ago. If you present a client with a bunch of options they start to get side tracked, coming up with all sorts of other things, instead of focusing on the project.
Try tele or video conferencing, or just exchanging e-mails instead of flying over everytime.  After you get them started on how to get the latest version (either via a SCC system, e-mail, etc.) and run it then you won't have to make so many trips. The idea behind rapid prototyping is that showing prototypes whittles down the options since the client has a more concrete idea of what they really want after seeing a couple of prototypes. Each prototype should get closer and closer to the actual feature set to be built. If not, then you need to spend more time talking with the client about the previous prototypes before prototyping another.
Paul Watson wrote:
Also believe me, I like prototyping, but when a client sees a prototype website which looks quite good and was created in two days, no amount of explanation will make them believe that the full website will take two months. They don't get that a prototype is slapped together, like a house made of string and tin foil and that a proper "house" will take much longer to build. They think you are ripping them off and bad blood enters the relationship.
I agree with you on that one and that it is a disadvantage of protoyping. However, I feel that properly educating the client that a prototype is just slapped together UI code and that a more robust and scalable solution requires considerably more effort would be effective for most cases.
Paul Watson wrote:
We have tried everything and find that rigid but small phases work best. Component by component, with sign off and around-the-board agreement.
I guess those methods are not for everyone. Use whatever works best and not just what everyone else is using. XP and Agile have worked well in previous development environments that I've been involved with and thus just have a bias towards those processes
|
|
|
|
|
There is one really great thing from XP that I use all the time: "Write the test programs first". I found it most helpful, although you need some self-discipline to make this work 
I vote pro drink ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
Yes, it does take a while to get into the habit of writing test programs before you write the code. After you write testing units a couple of times, you wonder how you ever lived without them Of course, if I'm on a deadline and don't have the luxury of doing so, then I just screw it and go ahead with writing the code  But if the code is to go into a reusable library, I'll usually invest the time in writing the testing modules to make it easier to perform regression testing when I go back into the library to change something.
|
|
|
|
|
Well,
For really big, complex or new systems it's almost inpossible to come up with
a correct design in the first place.
So there is the need to redefine and clearify the desing later on, as
the knowledge about the system to be build grows.
This is especialy true for systems build on new technology or in
a new application domain.
That's the reason I voted 3.
If the app to be created is an instance of an already good
understood business domain, than Option 1 is more likely to be
applicable.
I am a signature virus!
Help me spread and copy me to your sig!
Ooops I am infected
|
|
|
|
|
I am working with industrial systems that are not documented so I have to reverse engineer the code . Also I have prepare for a new system (largely undocumented) and I have my system talking to 3 other systems , all undocumented . Although the basics of my design where done before I started , facts uncovered during the work has led to several fundemental changes . The systems are in use 24 hours a day 7 days a week , there are no backup systems , there is no test system and every time I run a test it can stop the entire factory production for up to 40 minutes at a time. Design ? Yes please , but it aint always possible. In this case I would have spent several years documenting code that would have then been binned. I have to work to a rather vague and moveable IO spec that I have to generate as best I can by looking at the old code.
|
|
|
|
|
I disagree. I think that 6 is the only viable choice.
Yes, coding must wait until the design is fleshed out and everyone has had a chance to review and agree that it is ready to start coding on.
BUT. No design is ever implemented exactly the way that it was originally conceived. Has anyone ever started on a project and finished it without making changes to the the software spec? Sometimes even changes to the requirements are needed..
Because you are talking about commercial products here, the customer is involved. Even if you are making a product to be sold and not one on a contract, customers will have input into it's final design and their input is never the same as it was when the product was conceived.
just my 2 cents,
Sef Tarbell
West Des Moines, Iowa, USA
"A mind all logic is like a knife all blade, it makes the hand bleed that uses it." --Rabindranath Tagore
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
