Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Re: Planning your software before writing

by zigster (Hermit)
on Jan 08, 2001 at 22:41 UTC ( [id://50546]=note: print w/replies, xml ) Need Help??


in reply to Re: Planning your software before writing
in thread Planning your software before writing

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
  • Comment on Re: Re: Planning your software before writing

Replies are listed 'Best First'.
Re: Re: Re: Planning your software before writing
by chromatic (Archbishop) on Jan 08, 2001 at 23:31 UTC
    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.)

      Avoid using "SHOULD BE ABLE TO" when you write your stories in XP. Use "CAN" instead:
Re^3: Planning your software before writing
by dragonchild (Archbishop) on Oct 28, 2004 at 14:58 UTC
    http://extremeperl.org is an excellent introduction to XP, especially with a Perl bent.

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://50546]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (3)
As of 2024-06-25 04:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?
    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.