Modern Development Methodology?

[Ally]

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.

 

[Phlip]

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.

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.

 

[Daniel Dyer]

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.

 

[Phlip]

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.

 

[Stan Milam]

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.

 

[Pavel]

We use PSP (Personal Software Process). It's the most difficult process
but it really works.

 

[Daniel Dyer]

Daniel Dyer wrote;


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.

 

[Betty]

Google "Test Driven Development".



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.

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

 

[Phlip]

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.

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.

 

[Richard Bos]

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 Harter]

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, (e-mail address removed)
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

 

[Phlip]

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?

 

[Betty]

Uh, where's the automated tests?

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

 

[friedlinguini]

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.

 

[Phlip]

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.

 

[Gregory L. Hansen]

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?

 

[Betty]

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.

 

[Phlip]

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]

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.

 

[Betty]

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.