Re: Planning your software before writing

[chromatic]

Here's my take on things, (follow the link in neophyte's post for better reasoning and more cogent analysis):

• Software changes all the time
• Software requirements change all the time
• Doing a complete design up front is a big investment that pays less and less the more you change
• You can't predict what will happen more than a week or two in advance
• When you actually start coding, you'll find better ideas
• No one wants to update the design documentation while you're coding
• A large design at the start can lead you to the trap of making things too flexible, adding functionality you don't need just yet
• If the project is always in a functional state, you can deliver it to the customer nearly anytime
• If the customer chooses the features that provide the most business value and you work on them, you can maximize your return on investment
• Write the simplest code that could possibly work. It's easier to debug and to understand that way.

I'm not saying that design isn't important. I'm just saying that spending a couple of weeks at the start of a project doing nothing but design is not (in my experience) going to pay off in six months, when the specifications have changed, the original design didn't work, and no one wants to update a few dozen CASE diagrams or pages of UML.

Certain industries where accuracy and reliability need to be mathematically proven may have different requirements.

XP practitioners try to 'code by intent', where they write a test case for the feature they're about to add, let the test fail, then write code to make the test pass. That's design in the small.

For design in the large, they write stories about the features the software needs. The customer arranges them by their value in the shipped product, and the team tackles them in that order. Design is done as-you-go, with a little up front investment in the basic architecture (the simplest that could possibly work), breaking a story down into programmer-afternoon-sized-tasks, and continually refactoring.

That may or may not work for you, and it may or may not work for my latest project. We'll see.

[zigster]

OK hows about this... Design is important cause software engineering is hard. Gifted engineers are able to code with little written design as soon as other engineers are added then design becomes very important. Or to put it another way if you have one programmer who is dead smart then he (or she) may be able to skip the design phase and still produce a damn fine project. As the project grows in size the requirement for design rises exponentially. XP programming simply stated avoids the issues because it quite rightly says that design is hard so we wont do it. You have correctly explained why design is hard, all of your points are valid.. However it is important to realise the cost fractionalising the design, the benifit is easy to see. Picking a point at random: software requirements change all the time so in a traditional environment we will have to change the design and the code that takes lots of time. In our XP world we have no design to update so we only have to update the code (although I have written this flippantly I do not mean it be so this is a genuine reason why XP is good) The problem is you have no design so each change becomes a little harder to implemnt as the impact is harder to see because there is no big picture, because there is no design.

Formal design is required for the following (off the top of my head) reasons

• To allow agreement between developers upon interfaces and functionality. A large project will have many elements all ready to collide the design will ensure that they all use the same messaging protocol and so on.
• To provide a road map for developers to be able to explore code they did not write or were not invloved within (or have simply forgotten). No matter how good a developer is he (or she) will get up to speed more rapidly with a design document that code. Reverse engineering is hard (trust me that is what I am doing now)
• To allow for impact analysis to take place regarding changes to core processing.
• To provide a common understanding of where you are trying to get to before you arrive.
• ... and so on and so on
I have looked at XP with interest but never tried it. My impressions are all negative please let me know how you get on with it.. I would love to be wrong and for XP to work.. twould certainly make our lives easier.
--

Zigster

[chromatic]

Those are common criticisms of XP, and they're very understandable. I may not have explained it correctly, so I'll take a shot at clarifying. (I also don't mean to say that XP is a panacaea or suitable for everything. I'm just trying it with a couple of my projects, and it's working pretty well.)

It's not that design is hard, though it is, it's that up front design is very hard. That's why projects like the Gimp, Apache, Mozilla, and Slashcode are all facing fundamental rewrites. They invested some time in design before they started coding, but the uses and needs of their software grew beyond their original design. They designed themselves into a corner.

XP may or may not completely alleviate that -- it depends on your team's abilities. Instead, it says, "Design is good. Let's design all the time."

To address more of belize's post below, I'd take something like the Ultimate Bulletin Board, and write stories like the following:

• Users must be able to post comments
• Users should be able to see all comments arranged chronologically
• Comments should strip out dangerous HTML
• Moderators/administrators should be able to edit comments
• Moderators/administrators should be able to delete comments
• Users should be able to mark up their comments with smilies, bold, underlines, and italics
• Users should be able to edit their comments
• Moderators/administrators should be able to add their own markup
At some point in the future, you'll probably want to use a database for this, probably around the time you hit story 5. Are you going to bank on your ability to design the right db schema when you hit story two? XP would say that you should do as much as you can *without* adding that kind of infrastructure until you absolutely need to. Especially knowing that the requirements will change.

I, for one, would rather spend my resources completing the first few stories than building a database, arranging the tables just so, then having to modify the tables and convert the code four or five times. I'll probably have to do it once or twice, but the simpler the existing code and design by the time it is absolutely necessary to add the database, the less chaos there will be.

It's not a case of no design vs. full design, it's a case of design only as much as you need for the next two weeks vs. design everything.

One last what if... what if you spent a week designing the interface to a billing system your customer might want in a year, then he tells you that they have decided to use an existing front-end and want you to work on a batchloader? (Design what you need right now.)

[Anonymous Monk]

Avoid using "SHOULD BE ABLE TO" when you write your stories in XP. Use "CAN" instead:

[dragonchild]

http://extremeperl.org is an excellent introduction to XP, especially with a Perl bent.

[belize]

It is interesting that most of ther responses seem to assume a very large project. But a small company like ours deals with very small applications with very specific uses. Maybe what is needed is a guage of "small" versus "large".

How would you rank a project such as Infopop's "Ultimate Bulletin Board" which appears to be very successful and continually growing.

Or John Cokos "Hyperseek" search engine which has grown over the lsat few years.

If you are not familiar with either one:

http://www.infopop.com

http://www.interactive-web.net

Both of these appear to be small applications. But would require some heavy duty planning and documentation to maintain.

[puck]

With respect to the stories, the method I've been taught is that your programming team typically works on a two week cycle.

Every two weeks you have have a meeting with the customer. At this meeting you go over what has been completed. The customer then hands over the next set of stories and you only accept the amount of work you know you can do in two weeks.

In this manner you never have all the stories, you only work in the here and now.

There are more things to be taken into account here, but I won't bother with them at the moment...

Cheers!