Modern Development Methodology?

Discussion in 'Java' started by Ally, Apr 24, 2005.

  1. Ally

    Ally Guest

    Could someone give me an example of a modern development methodology? Just
    to see if I'm thinking along the right lines...

    P.S. Sorry for the cross posting but I couldn't find a newsgroup for systems
    analysis.
     
    Ally, Apr 24, 2005
    #1
    1. Advertising

  2. Ally

    Phlip Guest

    Ally wrote:

    > Could someone give me an example of a modern development methodology? Just
    > to see if I'm thinking along the right lines...


    Google "Test Driven Development".

    > P.S. Sorry for the cross posting but I couldn't find a newsgroup for

    systems
    > analysis.


    news:comp.software-eng

    Briefly put, write a test for everything, at every scale, and run all tests
    after the fewest possible edits. That technique rapidly creates rock-solid
    code that resists the kinds of bugs that require long arduous bug hunts.
    When code is easy and safe to change, you can split requirements into small
    features, implement these in order of business value, and release weekly.
    That strategy captures every aspect of development as a kind of test, with
    results that provide visibility for steering. Each week, you test that your
    project is more useful.

    --
    Phlip
    http://www.c2.com/cgi/wiki?ZeekLand
     
    Phlip, Apr 24, 2005
    #2
    1. Advertising

  3. Ally

    Daniel Dyer Guest

    On Sun, 24 Apr 2005 17:24:21 +0100, Ally <> wrote:

    > Could someone give me an example of a modern development methodology?
    > Just
    > to see if I'm thinking along the right lines...
    >
    > P.S. Sorry for the cross posting but I couldn't find a newsgroup for
    > systems
    > analysis.


    Agile methodologies such as eXtreme Programming
    (http://www.extremeprogramming.org/) are 'modern' and quite popular these
    days. But there isn't a one-size-fits-all methodology that is appropriate
    to all development. What are you building?

    This (http://www.fastcompany.com/online/06/writestuff.html) is an
    interesting article about a methodology for software development that
    gives a completely different perspective and makes an interesting point
    about bugs in the software vs. bugs in the process.

    Dan.


    --
    Daniel Dyer
    http://www.footballpredictions.net
     
    Daniel Dyer, Apr 24, 2005
    #3
  4. Ally

    Phlip Guest

    Daniel Dyer wrote;

    > Agile methodologies such as eXtreme Programming
    > (http://www.extremeprogramming.org/) are 'modern' and quite popular these
    > days. But there isn't a one-size-fits-all methodology that is appropriate
    > to all development.


    Sometimes there is. (The standard example is "wash your hands _before_
    performing surgery.")

    If we dismiss "extreme" as an appeal to developers' sense of mishchief, and
    "Agile" as marketecture, we are left with "Test".

    Thou shalt automate thy tests.

    --
    Phlip
    http://www.c2.com/cgi/wiki?ZeekLand
     
    Phlip, Apr 24, 2005
    #4
  5. Ally

    Stan Milam Guest

    Daniel Dyer wrote:
    > On Sun, 24 Apr 2005 17:24:21 +0100, Ally <> wrote:
    >
    >> Could someone give me an example of a modern development methodology?
    >> Just
    >> to see if I'm thinking along the right lines...
    >>
    >> P.S. Sorry for the cross posting but I couldn't find a newsgroup for
    >> systems
    >> analysis.

    >
    >
    > Agile methodologies such as eXtreme Programming
    > (http://www.extremeprogramming.org/) are 'modern' and quite popular
    > these days. But there isn't a one-size-fits-all methodology that is
    > appropriate to all development. What are you building?
    >
    > This (http://www.fastcompany.com/online/06/writestuff.html) is an
    > interesting article about a methodology for software development that
    > gives a completely different perspective and makes an interesting point
    > about bugs in the software vs. bugs in the process.
    >
    > Dan.
    >
    >


    Dan, this looks to be good stuff. There is definately a relationship
    between the software development process and bugs in the system. I
    remember my first big project was as a junior programmer. The senior
    programmer and architech really new his stuff. It was a lot of work buf
    fun. The next big project I was working for a couple of guys who could
    not program or design their way out of a paper bag. This was a lot of
    work and miserable. Daily I found big flaws in their design. They
    would say "good catch" then leave it up to me to find some way to fix
    it. Basically, I got paid a lesser salary to find their mistakes and
    fix them. In these latter days of my career I see the problems coming
    down the road, but I am too tired of being beat up for trying to make
    everyone aware. Now I quietly program solutions and when reality
    strikes I pull my solution like a rabbit out of a hat.

    Regards,
    Stan Milam.
     
    Stan Milam, Apr 24, 2005
    #5
  6. Ally

    Pavel Guest

    We use PSP (Personal Software Process). It's the most difficult process
    but it really works.
     
    Pavel, Apr 24, 2005
    #6
  7. Ally

    Daniel Dyer Guest

    On Sun, 24 Apr 2005 18:05:06 +0100, Phlip <> wrote:

    > Daniel Dyer wrote;
    >
    >> Agile methodologies such as eXtreme Programming
    >> (http://www.extremeprogramming.org/) are 'modern' and quite popular
    >> these
    >> days. But there isn't a one-size-fits-all methodology that is
    >> appropriate
    >> to all development.

    >
    > Sometimes there is. (The standard example is "wash your hands _before_
    > performing surgery.")
    >
    > If we dismiss "extreme" as an appeal to developers' sense of mishchief,
    > and
    > "Agile" as marketecture, we are left with "Test".
    >
    > Thou shalt automate thy tests.


    I'm not going to disagree about testing, but I would argue that that is
    only one aspect of a methodology and stand by my point about no one
    methodology being appropriate for all software. For example there is
    unlikely to be a methodology that is equally suited to developing
    MP3-playing sofware and space shuttle software. A bug in your MP3 player
    might affect the sound quality or cause it to crash occasionally. A bug
    in the shuttle software could cause several people to die in a very
    expensive explosion. For the MP3 player you might sacrifice a bit of
    quality in favour of ease of development and keeping costs low. For the
    shuttle, expense is secondary to quality.


    Dan.


    --
    Daniel Dyer
    http://www.footballpredictions.net
     
    Daniel Dyer, Apr 24, 2005
    #7
  8. Ally

    Betty Guest

    "Phlip" <> wrote in message
    news:8XPae.36$...
    > Ally wrote:
    >
    > > Could someone give me an example of a modern development methodology?

    Just
    > > to see if I'm thinking along the right lines...

    >
    > Google "Test Driven Development".
    >
    > > P.S. Sorry for the cross posting but I couldn't find a newsgroup for

    > systems
    > > analysis.

    >
    > news:comp.software-eng
    >
    > Briefly put, write a test for everything, at every scale, and run all

    tests
    > after the fewest possible edits. That technique rapidly creates rock-solid
    > code that resists the kinds of bugs that require long arduous bug hunts.
    > When code is easy and safe to change, you can split requirements into

    small
    > features, implement these in order of business value, and release weekly.
    > That strategy captures every aspect of development as a kind of test, with
    > results that provide visibility for steering. Each week, you test that

    your
    > project is more useful.
    >
    > --
    > Phlip
    > http://www.c2.com/cgi/wiki?ZeekLand
    >

    Where is the part where you find out what the program is supposed to do?
     
    Betty, Apr 24, 2005
    #8
  9. Ally

    Phlip Guest

    Betty wrote:

    > Where is the part where you find out what the program is supposed to do?


    You review the features, as they grow, with Someone who has the full-time
    job of researching what the program is supposed to do.

    If you can't get that Someone, then, gosh, you might not have the charter
    for a healthy project.

    If that Someone tells you a feature is now finished, you don't argue.

    And you never do too much before reviewing the feature, so you never need to
    backtrack too far.

    That Someone will request features in order of business value, so you can
    deploy a release to real users as early as possible. This also helps prevent
    rework.

    Daniel Dyer wrote:

    > This (http://www.fastcompany.com/online/06/writestuff.html) is an
    > interesting article about a methodology for software development that
    > gives a completely different perspective and makes an interesting point
    > about bugs in the software vs. bugs in the process.


    Then the article ends with this:

    "The most important things the shuttle group does -- carefully planning the
    software in advance, writing no code until the design is complete, making no
    changes without supporting blueprints, keeping a completely accurate record
    of the code -- are not expensive. The process isn't even rocket science. Its
    standard practice in almost every engineering discipline except software
    engineering."

    Those things are important for all software development, but the author
    misses some major points. Aerospace software has a long legacy of
    incremental development. No such software has _ever_ been _completely_
    planned in advance. The developers write lots of code _before_ carefully
    planning the next design change.

    Such development invests in infrastructure that makes the software as safe
    as possible to change.

    What's totally remarkable is these techniques (specifically, the test-first,
    pair programming, and continuous integration) can scale _down_ from
    aerospace software development, to the speed of ordinary business
    development.

    --
    Phlip
    http://www.c2.com/cgi/wiki?ZeekLand
     
    Phlip, Apr 25, 2005
    #9
  10. Ally

    Richard Bos Guest

    "Ally" <> wrote:

    > Could someone give me an example of a modern development methodology? Just
    > to see if I'm thinking along the right lines...


    No, but apparently, the nameless method which consists of planning
    ahead, coding meticulously, and desk-checking and debugging thoroughly,
    isn't modern enough any more.

    Richard
     
    Richard Bos, Apr 26, 2005
    #10
  11. On Tue, 26 Apr 2005 13:25:50 GMT, (Richard
    Bos) wrote:

    >"Ally" <> wrote:
    >
    >> Could someone give me an example of a modern development methodology? Just
    >> to see if I'm thinking along the right lines...

    >
    >No, but apparently, the nameless method which consists of planning
    >ahead, coding meticulously, and desk-checking and debugging thoroughly,
    >isn't modern enough any more.


    How utterly twenty centurieth. Get with the program, dude.


    Richard Harter,
    http://home.tiac.net/~cri, http://www.varinoma.com
    Save the Earth now!!
    It's the only planet with chocolate.
     
    Richard Harter, Apr 26, 2005
    #11
  12. Ally

    Phlip Guest

    Richard Bos wrote:

    > No, but apparently, the nameless method which consists of planning
    > ahead, coding meticulously, and desk-checking and debugging thoroughly,
    > isn't modern enough any more.


    Uh, where's the automated tests?

    --
    Phlip
    http://www.c2.com/cgi/wiki?ZeekLand
     
    Phlip, Apr 26, 2005
    #12
  13. Ally

    Betty Guest

    "Phlip" <> wrote in message
    news:sIsbe.1190$...
    > Richard Bos wrote:
    >
    > > No, but apparently, the nameless method which consists of planning
    > > ahead, coding meticulously, and desk-checking and debugging thoroughly,
    > > isn't modern enough any more.

    >
    > Uh, where's the automated tests?
    >

    The customer does them when you dump the code in their lap ;-)
     
    Betty, Apr 26, 2005
    #13
  14. Ally

    Guest

    Richard Bos wrote:
    > "Ally" <> wrote:
    >
    > > Could someone give me an example of a modern development

    methodology? Just
    > > to see if I'm thinking along the right lines...

    >
    > No, but apparently, the nameless method which consists of planning
    > ahead,


    Which you should do, though requirements are often fluid. Nobody would
    advocate painting yourself into a corner when you already know where
    the door is, but requirements can be very fluid these days. A
    cornerstone of good OO design is ensuring good functionality with a
    minimum of interface. When this is done well it can lessen the
    importance of the big picture.

    > coding meticulously,


    Nice, but not really a process issue. It's more a product of
    programmer talent and available resources.

    > and desk-checking


    As code changes the desk-checking has to be repeated many times.
    Fortunately we have computers to automate well-defined tasks. Hence
    assertions and automated unit tests.

    > and debugging thoroughly,


    Unit tests, assertions, and other forms of defensive programming
    hopefully reduce the bug count up-front. Beyond that, debugging hasn't
    changed much as long as the higher-ups give you enough time and
    resources to do so.

    > isn't modern enough any more.
    >


    Perhaps not, but they haven't disappeared either. No process is an
    adequate substitute for smart programmers, and smart programmers use
    and adapt processes as needed to get the job done right.
     
    , Apr 26, 2005
    #14
  15. Ally

    Phlip Guest

    Betty wrote:

    > > > No, but apparently, the nameless method which consists of planning
    > > > ahead, coding meticulously, and desk-checking and debugging

    thoroughly,
    > > > isn't modern enough any more.

    > >
    > > Uh, where's the automated tests?
    > >

    > The customer does them when you dump the code in their lap ;-)


    That is why getting them to sign off on all the requirements, before you
    start, is absolutely critical.

    When you deliver the actual product, after finishing all the requirements,
    that's the first time they get to discover that what they asked for is not
    what they really need.

    You still get paid, because you made them sign. Then you get to gouge them
    for every change request.

    --
    Phlip
    http://www.c2.com/cgi/wiki?ZeekLand
     
    Phlip, Apr 26, 2005
    #15
  16. In article <VKPae.6176$>,
    Ally <> wrote:
    >Could someone give me an example of a modern development methodology? Just
    >to see if I'm thinking along the right lines...
    >
    >P.S. Sorry for the cross posting but I couldn't find a newsgroup for systems
    >analysis.
    >
    >



    I've been reading a book about OOP by an author that favors iterative
    design. As I understand it, in each cycle you spend a few days on
    requirements, then about four weeks on design, coding, and testing. What
    is produced is not prototyping, but production quality code that is
    incomplete. The process repeats with each cycle beginning with
    requirements, which may change over time, and then developing some subset.

    Does anyone else know of that?


    --
    "I fart for joy and I laugh more than if I had cast my old age, as a
    serpent does its skin." -- Aristophanes, Peace, 421 BC
     
    Gregory L. Hansen, Apr 26, 2005
    #16
  17. Ally

    Betty Guest

    "Phlip" <> wrote in message
    news:sOube.1214$...
    > Betty wrote:
    >
    > > > > No, but apparently, the nameless method which consists of planning
    > > > > ahead, coding meticulously, and desk-checking and debugging

    > thoroughly,
    > > > > isn't modern enough any more.
    > > >
    > > > Uh, where's the automated tests?
    > > >

    > > The customer does them when you dump the code in their lap ;-)

    >
    > That is why getting them to sign off on all the requirements, before you
    > start, is absolutely critical.
    >
    > When you deliver the actual product, after finishing all the requirements,
    > that's the first time they get to discover that what they asked for is not
    > what they really need.
    >
    > You still get paid, because you made them sign. Then you get to gouge them
    > for every change request.
    >

    Welllllll now ;-)
    Extreme programming would have you meeting with the customer every
    week or two. During this little tête-à-tête, you show them what you've got
    and they get to change the requirements.
     
    Betty, Apr 26, 2005
    #17
  18. Ally

    Phlip Guest

    Betty wrote:

    > Extreme programming would have you meeting with the customer every
    > week or two. During this little tête-à-tête, you show them what you've got
    > and they get to change the requirements.


    Wrong. XP has the "customer" onsite. This is another way to say "researching
    the requirements is a full-time job for an expert". If your users are
    farmers, you need a real farmer, onsite, for best results.

    The customer helps convert requirements into testable specifications, and
    reviews features as they grow.

    The team _could_ release any integration. They make a ceremony of releasing
    a new version, once a week. The customer already knows exactly what's in it.
    This lets them calculate velocity and plan the next week.

    Some teams release to real customers, or demo to external managers, once a
    week.

    --
    Phlip
    http://www.c2.com/cgi/wiki?ZeekLand
     
    Phlip, Apr 26, 2005
    #18
  19. Ally

    Phlip Guest

    Gregory L. Hansen wrote:

    > I've been reading a book about OOP by an author that favors iterative
    > design. As I understand it, in each cycle you spend a few days on
    > requirements, then about four weeks on design, coding, and testing. What
    > is produced is not prototyping, but production quality code that is
    > incomplete. The process repeats with each cycle beginning with
    > requirements, which may change over time, and then developing some subset.
    >
    > Does anyone else know of that?


    Try requirements -> test -> code -> design (refactoring). That lets
    requirements lead. You can delete code that has no test based on a real
    requirement. The efficiencies let you use 1 week iterations, not 1 month.

    --
    Phlip
    http://www.c2.com/cgi/wiki?ZeekLand
     
    Phlip, Apr 26, 2005
    #19
  20. Ally

    Betty Guest

    "Phlip" <> wrote in message
    news:rJvbe.1230$...
    > Betty wrote:
    >
    > > Extreme programming would have you meeting with the customer every
    > > week or two. During this little tête-à-tête, you show them what you've

    got
    > > and they get to change the requirements.

    >
    > Wrong. XP has the "customer" onsite. This is another way to say

    "researching
    > the requirements is a full-time job for an expert". If your users are
    > farmers, you need a real farmer, onsite, for best results.


    How did you find out that I'm a farmer. Hay, if I spend all day in
    a skyscraper in Chicago reviewing all this crap (I just need a program
    to count milk production), who is going to milk my cows. Maybe I should
    ask microsoft to do it.

    > The customer helps convert requirements into testable specifications, and
    > reviews features as they grow.
    >
    > The team _could_ release any integration. They make a ceremony of

    releasing
    > a new version, once a week. The customer already knows exactly what's in

    it.
    > This lets them calculate velocity and plan the next week.
    >
    > Some teams release to real customers, or demo to external managers, once a
    > week.
    >
    > --
    > Phlip
    > http://www.c2.com/cgi/wiki?ZeekLand
    >
    >
     
    Betty, Apr 26, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Imran Aziz
    Replies:
    2
    Views:
    1,245
    Imran Aziz
    Aug 5, 2005
  2. Ally
    Replies:
    20
    Views:
    881
    Phlip
    Apr 26, 2005
  3. Ally

    Modern Development Methodology?

    Ally, Apr 24, 2005, in forum: C Programming
    Replies:
    22
    Views:
    721
    Phlip
    Apr 26, 2005
  4. jaialai technology
    Replies:
    7
    Views:
    647
    James Kanze
    Dec 20, 2009
  5. Replies:
    2
    Views:
    89
    Kirk Haines
    Mar 26, 2006
Loading...

Share This Page