Agile Attitudes- House of Cards

Mon Jun 27 11:23:22 EDT 2005

Agile Attitudes
Volume 2, Issue 07                                    June 28, 2005
                 A free bi-weekly email newsletter
                        Brought to you by
                     Agile Rules consulting
                       www.agilerules.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Welcome to Agile Attitudes, a newsletter of ideas, insights and
technical tips that help people find better ways to develop
software. Feel free to share this with anyone - just be sure you
send or print the whole thing, including the copyright notice.

Directions for managing your subscription are below.

                         O><O><O><O><O><O
Agile Rules will be presenting a tutorial on TDD for Embedded
Software development at the upcoming Agile 2005 Conference in Denver
on July 26.

We'll present a short version of this tutorial at the next 
Agile Bazaar meeting on July 14 at Tufts. Details to be announced on
AgileBazaar email list.

Agile related meetings and other events in the Boston area are 
discussed on the Agile Bazaar email list. For info see:
http://groups.yahoo.com/group/AgileBazaar/

                         O><O><O><O><O><O
If you would like to receive an email as soon as we know of
an event in the Boston area of interest to the agile software
community, you can sign up for the announcements list at
http://www.agilerules.com/mailman/listinfo/agileannounce

                         O><O><O><O><O><O
                         A House of Cards
          by Ron Morsicato and Nancy Van Schooenderwoert

Most of us have been trained on the job (and remarkably not in school)
to develop a product in stages. There is a requirements analysis stage,
followed by a design phase, and after reviews and many months of
anticipation an actual coding phase. That's followed by a Validation
and Verification phase, where oft times it's discovered that the
software hadn't turned out to be everything it could be, at least to
the eye of the user. We have been instilled with the philosophy to
"Plan our walk, and walk our plan."

In this newsletter we want to comment on the fallout of designing a
system to a tee before actually observing it operate. The biggest
problem is feedback. Designers do indeed crave it, but by having
to wait for a system they instead turn to analysis and simulation.
Both of these techniques, unfortunately, force the designer to make
a set of assumptions, and humans, no matter how experienced and
insightful, do err when making assumptions. Sometimes the error
is benign or only a slight inconvenience, but sometimes, and perhaps
too often, a system is based on an incorrect assumption that is a
showstopper.

Here's an example: Nancy worked on a large military vehicle system 
once where the sytems engineers had created a 4,000 page 
specification document, but the software people were just getting 
started on the first release. Later on in the project, management 
brought in a consultant to untangle the mess that the software had 
become. Nancy had a number of conversations with this consultant. 
The central question was: If everything had been so carefully 
planned, why all these problems? 

The spec listed what every software function would do, what 
parameters it would receive, and every other module it would talk 
to. Every detail had been thought out. That was precisely the 
problem! The tasking model of that CPU wouldn't allow the code 
to be written just as the systems engineers had envisioned. It 
had to be organized differently in order to take advantage of the 
processor's capabilities. 

Some of the software people understood that issue, but they only 
came into the picture after the spec was written. They were told 
to just code to the spec. This turned out to be a textbook example 
of why dialogue among groups, and incremental development are 
better than going too far on assumptions.

One study of military projects tallied a success rate of a whopping 2%.
So why is it that projects continue to do that "Big Design up Front?"
Perhaps, as one frequent contributor to agile lists has suggested, it
gives people the "illusion of control." After all, if the simulations
work, it must be a design that works. But when it is found out that the
system can't be built as designed, the reality sets in that you've got
nothing but a fragile house of cards.

The next newsletter issue will cover the Agile answer to this issue.

                         O><O><O><O><O><O
More articles on Agile software topics at http://www.agilerules.com
Within our company we have a sub-specialty in embedded systems.
Our site has articles on embedded XP and we support a discussion
list focused on the use of agile methods for building embedded
software. The list signup info is at
http://www.agilerules.com/mailinglists.phtml

                         O><O><O><O><O><O
To help you get started with in-depth research into Agile Attitudes
topics, we have added a Library section to our web site at
http://www.agilerules.com/library.phtml
Order using our links and receive discounts up to 30%!

                         O><O><O><O><O><O
If you enjoyed this issue or found it useful, forward it to a
friend! Help spread the word about better ways to build software.
Invite your friends and colleagues to join our growing reader
community at http://www.agilerules.com/mailinglists.phtml

                         O><O><O><O><O><O
Looking for a speaker for your next corporate or society meeting?
We present dynamic, informative programs on topics of interest
to managers and technical staff in their transition to more
flexible, robust ways to create software.

                         O><O><O><O><O><O
Want to reprint this issue in your company or society newsletter?
For permission to reprint any of the articles, contact us at
info at agilerules.com.

                         O><O><O><O><O><O

Your feedback is welcome! Send feedback to info at agilerules.com

To manage your subscription:
http://www.agilerules.com/mailman/listinfo/agileattitudes

                         O><O><O><O><O><O
            Brought to you by Agile Rules consulting
              162 Marrett Road, Lexington MA 02421

              Copyright (c) 2004, 2005 Agile Rules
                       info at agilerules.com

                         O><O><O><O><O><O
Privacy notice: We will not release a subscriber's address to any
third party for any reason. This is a strictly opt-in newsletter.
No one is ever subscribed without their explicit request.