Searching \ for '[OT]: Software development methodologies (was [OT]' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=
Search entire site for: 'Software development methodologies (was [OT]'.

Exact match. Not showing close matches.
PICList Thread
'[OT]: Software development methodologies (was [OT]'
2007\04\11@213413 by Vitaliy

flavicon
face
Nigel Duckworth wrote:
> Interesting page on how they manage code for the Space Shuttle;
>
> http://www.fastcompany.com/online/06/writestuff.html

A great example of how NOT to develop software. Expensive, slow,
inefficient.


I've recently attended the "Agile Software Development Fundamentals" course
from ASPE Tech (http://www.aspetech.com). I highly recommend it, as well as the
book that the course is primarily based on -- "Agile Software Development"
by Alistair Cockburn.

The principles behind the Agile are summarized in the Agile Manifesto, and
the Principles behind the Agile Manifesto:

http://www.agilemanifesto.org/principles.html

Let's contrast the two philosophies (S: Space Shuttle approach, A: Agile
approach). I will be quoting from both Agile documents, as well as the OP's
article.



S: "At the on-board shuttle group, about one-third of the process of writing
software happens before anyone writes a line of code. NASA and the Lockheed
Martin group agree in the most minute detail about everything the new code
is supposed to do -- and they commit that understanding to paper, with the
kind of specificity and precision usually found in blueprints"

You can't digest EVERYTHING into a series of simple steps. The specs have to
be only *sufficient* for the person reading them to understand the problem
and implement the solution. If you want to have rules for everything, then
you have to have rules for following the rules. Then you'd need rules
describing how to follow the rules for following the rules. It doesn't end.

A: "Working software over comprehensive documentation"
"Working software is the primary measure of progress."

Just enough documentation -- not less, but also not more. At the point where
documentation starts becoming a waste of time, stop. Initial documentation
will change anyway, no reason to "describe every minute detail" of a feature
that will later be dropped or replaced by another feature.

" Simplicity--the art of maximizing the amount of work not done--is
essential."



S: Believes that changes are bad, and should be as difficult as possible to
implement.
"... no coder changes a single line of code without specs carefully
outlining the change. Take the upgrade of the software to permit the shuttle
to navigate with Global Positioning Satellites, a change that involves just
1.5% of the program, or 6,366 lines of code. The specs for that one change
run 2,500 pages, a volume thicker than a phone book. The specs for the
current program fill 30 volumes and run 40,000 pages."

2500 pages of specs for about four pages of code, for about 127 pages of
actual code. If it isn't ridiculous, I don't know what is.

A: Values "responding to change over following a plan."
"Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage."

Document the change, but don't go overboard. 'Just enough' is enough.



S: "Everyone has his or her own small office."  With a door, I bet -- to
help isolate the programmers from each other. Meetings are infrequent, and
extremely boring:

"The meeting is a classic NASA performance -- a rehearsal for an almost
identical meeting several weeks away. It consists of walking through an
enormous packet of data and view -- graphs which describe the progress and
status of the software line by line. Except for Keller's occasional asides,
the tone is businesslike, almost formal, the view - graphs flashing past as
quickly as they can be read, a blur of acronyms, graphs, and charts."

A: "The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation."

Meetings are very informal, there's a constant flow of information between
the programmers. Theory behind the program is more important than the actual
code or program details. Collaboration is essential, all programmers are in
the same room, pair programming is encouraged. Working software is delivered
at frequent, regular intervals (~once every 2 weeks).



S: "The whole approach to developing software is intentionally designed not
to rely on any particular person."

A: Values "individuals and interactions over processes and tools". People
are everything. Cockburn cites a study that found no significant correlation
between the tools or methodologies and project success. Project success is
dependent on the kind of people that are working on it. Software is not
being delivered? Fire the poor performers, and replace them with programmers
that will deliver good software.



One thing I noticed about the article, is its frustrated tone "why can't
everybody just be like the Shuttle folks?!" The answer is, their approach
goes contrary to the way humans work, and it would not be sustainable in the
real business environment. The reason the shuttle folks are producing code
that is relatively free of bugs, is not because of "The Process", but
because:

- The project has a $35M *guaranteed* annual budget. That's $83 per line of
code, PER YEAR. And not just new code, but EXISTING code as well!

- The project duration is indefinite -- development has been going on for
decades.

- There is strong resistance to change, which translates to fewer
opportunities for errors -- at the expense of flexibility, but that's
besides the point.

- There are 260 programmers working on the project. About 32 pages of code
that rarely changes, per programmer. I'd be interested to know how many
lines of new code are added every year. Considering that the number of lines
given (420,000) for the last three versions is the same, I would think not
many.

- The job is very cozy: stable work environment, 8-5 days, five day weeks,
with all the government benefits and an average estimated salary of $100k
(I'm assuming that since the product is software, most of the $35M budget
goes to pay the programmers). I believe this is the biggest contributor to
the error-freeness of the code: the project retains the people who really
understand how the program works. I don't buy the "intentionally designed
not to rely on any particular person" argument -- without people who
understand the theory behind the program, the project would be dead. Just
imagine how much time it would take to read the 40,000 pages of project
documentation.

The ironic thing is, despite the tremendous human and financial resources,
the group software delivered is STILL BUGGY! I don't understand where the
author got the idea of "near-perfect results": the shuttle software is
routinely the cause of launch delays, and in the article itself there's an
example of the software failing:

"The software was confused because of a programming error. As the wrist of
the remote arm approached a complete 360-degree rotation, flawed
calculations caused the software to think the arm had gone past a complete
rotation -- which the software knew was incorrect. The problem had to do
with rounding off the answer to an ordinary math problem, but it revealed a
cascade of other problems."

We're lucky that most software companies are not like the shuttle group.

Vitaliy

2007\04\12@182413 by Vitaliy

flavicon
face
Gerhard Fiedler wrote:
>> Vitaliy wrote
>>>Nigel Duckworth wrote:
>>>> Interesting page on how they manage code for the Space Shuttle;
>>>>
>>>> www.fastcompany.com/online/06/writestuff.html
>>>
>>>A great example of how NOT to develop software. Expensive, slow,
>>>inefficient.
>>
>> I wouldn't say it is how not to develop it.
>
> I don't think it's the methodology. There have been successful software
> projects before the Agile movement :)  Not every team is suited for every
> methodology.

True, but some methodologies, objectively speaking, are worse than others.
There are many examples where documentation was taken to the extreme, and
killed the project. Looking back, we had a couple of projects like that in
the past (we refer to those as 'frozen', not 'dead'). The most successful
projects (in terms of performance vs cost) were done when documentation was
kept to a bare minimum.

> It's something else that makes the distinction. Somewhat similar to what
> makes an electronic design a good one :)

That's one of the points I made in my original post, which is the
cornerstone of Agile: programming is about people. Good programmers can make
a project successful *despite* a bad methodology, and conversely bad
programmers can ruin a project even when the best available methodology is
used.

Vitaliy

2007\04\12@183923 by Vitaliy

flavicon
face
Alan B. Pearce wrote:
>>Nigel Duckworth wrote:
>>> Interesting page on how they manage code for the Space Shuttle;
>>>
>>> www.fastcompany.com/online/06/writestuff.html
>>
>>A great example of how NOT to develop software. Expensive, slow,
>>inefficient.
>
> I wouldn't say it is how not to develop it. As an example of how not to
> develop software, try the UK National Health Service software project, the
> UK Benefits system software, and IIRC the UK IRS software, all very large
> software projects that have gone way over budget, don't provide anything
> like the required functionality, and are at a point where they won't ever
> do
> so. I suspect between them they have a far higher cost per line than the
> shuttle software, and won't ever work.

The fact that these other projects you mentioned are worse, don't make the
shuttle group methodology acceptable. :)

I think the lesson here is to not let the government develop software,
period. Any time you give an organization unlimited budget, you can be sure
that lots of money will be wasted.

IMHO, a much better approach is to let companies bid on a project, and not
allow the original bid to be altered (e.g., not give the company more money
than it originally asked for). The most efficient organizations are small
private companies.

Vitaliy

2007\04\13@083203 by Gerhard Fiedler

picon face
Vitaliy wrote:

> The most successful projects (in terms of performance vs cost) were done
> when documentation was kept to a bare minimum.

I'd say that the most successful projects in this sense are where
/everything/ is kept to the bare minimum needed to achieve the goals. The
problem with this is not this simple (and rather obvious) rule, but the
fact that when you are below the minimum in one area, the required effort
in other areas can be much more higher than the economy in the
below-minimum area. Finding this sweet spot of a global minimum is more an
art than a science.

I've probably seen more projects going down the drain because of
insufficient documentation (and scope clarification) before starting coding
than because of excessive documentation. There are quite a few things you
can (and should) find out before writing the first line of code (or
thinking about components and circuit structures you're going to use).
There are of course other things you'll only be able to find out after you
have a first prototype, and trying to nail them down before is mostly a
waste of time.

Gerhard

2007\04\13@174438 by Nate Duehr

face
flavicon
face
On 4/11/07, Vitaliy <spam_OUTspamTakeThisOuTspammaksimov.org> wrote:
>
> Nigel Duckworth wrote:
> > Interesting page on how they manage code for the Space Shuttle;
> >
> > http://www.fastcompany.com/online/06/writestuff.html
>
> A great example of how NOT to develop software. Expensive, slow,
> inefficient.
>
>
> I've recently attended the "Agile Software Development Fundamentals"
> course
> from ASPE Tech (http://www.aspetech.com). I highly recommend it, as well as the
> book that the course is primarily based on -- "Agile Software Development"
> by Alistair Cockburn.
>

Welcome to the church.  Agile is just another methodology/religion.

I work in SUPPORT and integration of some pretty complex telecom systems.
I've seen crap code from every type of methodology out there.

The ONLY thing I KNOW works 100% of the time, is tying whether or not the
software WORKS to the engineer's WALLET.

Here's how it usually works in most companies:
Engineer hits ship date... bonus... bugs and major problems with that
code... oops... we already gave the engineer a bonus.  BAD BUSINESS.

How it SHOULD work:
Engineer told up front that bonus based on number of major/minor bugs in
system after release.  Bonus paid out over time.  THEN the time estimates
and ship dates are set.  Manager and Engineer learn to figure out how to
properly negotiate ship dates or they kill each other trying.  Then the
product is written/released and performance over time is tracked by the
SUPPORT department, not the Engineering management.  Bonus or lack thereof
is based on customer and support staff pain levels caused by bad code.

People only pay attention to detail if they're motivated to do so.  Taking
money away (or not giving it) is an incredible motivator.

Nate

2007\04\13@182820 by Vitaliy

flavicon
face
Nate Duehr wrote:

> Welcome to the church. Agile is just another methodology/religion.

Debatable.

If I remember correctly, last time we had a discussion on the subject, it
was decided (decreed by James? -- doesn't matter..) that religion must have
a deity.

> I work in SUPPORT and integration of some pretty complex telecom systems.
> I've seen crap code from every type of methodology out there.

I think it's reasonable to say that some methodologies are more conducive to
producing crap code, no?  Can you really NOT follow ANY methodology?

> The ONLY thing I KNOW works 100% of the time, is tying whether or not the
> software WORKS to the engineer's WALLET.

No amount of money will ever make a bad programmer produce good software. So
obviously, it doesn't work 100% of the time. What works is *hiring* good
programmers in the first place, and motivating them to do a good job.

{Quote hidden}

Have you ever seen this done anywhere? The problem I see is metrics.

Do you assign a fixed penalty (per bug), or go by the percentage (X bugs per
Y lines of code)? Does it matter what kind of code (simple, or involving
complex algorithms)?

Does the support department have an objective measure of the impact of a
particular bug on the product's performance? Or does the Engineering
department go without a bonus, simply because someone in the Support
department is having a bad day?

I think that one of the solutions is to have someone from outside both the
Support and Engineering departments decide who gets the bonus. That would
assure at least some level of objectivity.

> People only pay attention to detail if they're motivated to do so.  Taking
> money away (or not giving it) is an incredible motivator.

Money is not the only (and not the most important) motivator. Surveys
consistently demonstrate that it's not at the top of most people's list of
things that make a good job. Salary offered must be competitive, but things
like "interesting work", "a good boss", and "growth opportunities", tend to
be higher priorities than money.

Vitaliy

2007\04\13@220246 by Nate Duehr

face
flavicon
face
On 4/13/07, Vitaliy <.....spamKILLspamspam@spam@maksimov.org> wrote:
>
> Nate Duehr wrote:
>
> > Welcome to the church. Agile is just another methodology/religion.
>
> Debatable.
>
> If I remember correctly, last time we had a discussion on the subject, it
> was decided (decreed by James? -- doesn't matter..) that religion must
> have
> a deity.


LOL.  Nice.

I think it's reasonable to say that some methodologies are more conducive to
> producing crap code, no?  Can you really NOT follow ANY methodology?


True.  Crap is crap.  Or as a co-worker once said, "I give up, all we can do
is polish this turd."

Once you get beyond something a single coder can write, you need at least a
framework that everyone works from.

> The ONLY thing I KNOW works 100% of the time, is tying whether or not the
> > software WORKS to the engineer's WALLET.
>
> No amount of money will ever make a bad programmer produce good software.
> So
> obviously, it doesn't work 100% of the time. What works is *hiring* good
> programmers in the first place, and motivating them to do a good job.


Great point.  This article does a pretty good job of describing how not to
hire the bad ones:

http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html

{Quote hidden}

No, which is why I believe it has merit.  (GRIN)  Ultimately in a support
group you're paid by only a few factors, and one of them that's objective is
whether or not you know how to fix things properly and/or provide
workarounds in a way the customer is not upset.

(Bigger picture, you're paid if customers keep signing service contracts.
Ironically if the code were perfect, and easy to use/install, the service
contracts would cost less and there'd be very few support people.  When
engineers screw up, they guarantee I still have a job... so, by suggesting
ways to make our products permanently better, I'm technically working myself
out of a job, right?  This is one of the horrible deep Catch-22's of the
software support industry.)

But engineers are rarely paid for what they actually do, they're paid for
release dates... release junk, you still released ahead of schedule, and you
still have a job and a bonus... as long as you met the general
requirements.  Many times engineers can even convince managers to drop
important requirements near the end of a project, because guess what... the
manager's bonus is based on the release date too...  That's just wrong.

Do you assign a fixed penalty (per bug), or go by the percentage (X bugs per
> Y lines of code)? Does it matter what kind of code (simple, or involving
> complex algorithms)?


Simple.   Did it work for the customer?

(The same metric any small developer or business uses daily to prioritize
their work, or they go out of business.)

All the other metrics, in the end, don't matter.

Does the support department have an objective measure of the impact of a
> particular bug on the product's performance? Or does the Engineering
> department go without a bonus, simply because someone in the Support
> department is having a bad day?


Come now... not just one person would determine this.

Have you seen the rediculous number and types of metrics most large support
departments have these days...?  Ticket systems have grown into their own
world of multi-million-dollar systems (after you pay all the consultants to
upgrade the thing because it's so complex no one in your own organization
can even work on it at that level).

A management review of the open issues would easily quantify the open
tickets for customer impact.  Major, minor, and don't care... but even minor
stuff will ALWAYS come back to bite you later, I've learned.  Almost every
single time I've heard an engineer say, "We couldn't get to that in this
release", the customer comes screaming back later asking where it is.
People in all three groups (engineering, support, and customer) aren't as
dumb as many engineers would like to think.  If the engineer and the support
person both agree that the customer is probably going to want it, the
customer will.

I think that one of the solutions is to have someone from outside both the
> Support and Engineering departments decide who gets the bonus. That would
> assure at least some level of objectivity.


Sure.  Fine.  Sales?  LOL!

Technicians peer's should be technicians.  But that's just my opinion.

{Quote hidden}

They only say that AFTER they have a job and are getting paid.  Ask anyone
without a job.  Maslow's Heirarchy of Needs skews those surveys, because
they only ask those survey questions of people who already have jobs.  The
few that will stand on principal and not work because they want something
"more interesting" when they can't pay the rent, are few and far between.

:-)

Nate

2007\04\14@001557 by William Chops Westfield

face picon face
>>  What works is *hiring* good programmers in the first place, and
>>  motivating them to do a good job.

Oh don't be silly.  As long as everyone follows the procedures set forth
in the company's ISO9000 documents, they can't help but produce fine
products.  An individual's ability or lack thereof has nothing to do
with producing quality.

BillW

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...