Agile Attitudes- Like Money in the Bank

[agileattitudes at agilerules.com]

Agile Attitudes
Volume 2, Issue 4 Feb. 23, 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
Watch this space for announcements concerning opportunities to
hook up with the growing agile software development community

O><O><O><O><O><O
Like Money in the Bank
by Ron Morsicato

If you read the Agile Manifesto, http://www.agilemanifesto.org/, you
will note that the founders of the agile movement value “Working
software over comprehensive documentation.” They mean what they say,
and in a big way. In a truly agile environment, you will not find
more code-specific documentation than what is needed in the short
term, and once it has served its purpose it is discarded. But isn't
there a problem here? A large, detailed bank of documentation allows
new developers and maintainers down the road to understand how the
system works so they can contribute to its development or maintenance.

I do not deny that it is important to have this mechanism in place.
The point is that a comprehensive set of documentation is a poor
way to achieve this result. It needs to be maintained. Worse, it
tends to be constricting. Anyone who becomes adept at a game learns
how to delay decisions until an optimal moment, that moment when
maximum knowledge and understanding are achieved. When you do a
detailed design prior to coding, you are ignoring the information
that comes from observation of tests, and are forced to make
decisions far in time from the technical and business environments
within which the software will be operating. And to tell you the
truth, my experience as a developer has convinced me that it is
never used. You see, no matter how an organization claims to follow
a process that keeps documentation current, before you make changes
to code, you simply have to examine the code to make sure it's
consistent with the documentation. You end up going right to the
code! The agile approach is to make it easier to learn how the code
works from the code itself.

Well-tested code is self-documenting. I can read a subsection in a
detailed design document that tells me that such and such a method
does this and that. The agile alternative is to observe a test that
shows that this existing code behaves correctly.

What if I realize that similar functionality is desired elsewhere?
An object oriented approach is to refactor by making a method that
covers what is common in the two instances of functionality, and
derive specific methods from the higher-level one that meets the
demands required to implement the specific functionalities. When I
do this, I make sure there is now a test for each of the three new
methods, and delete the test for the original method from the test
suite. I now have the current design documented in an up-to-date
fashion. It's nearly painless if I use the Test Driven Development
paradigm, where I write the new tests, made sure they fail because
the specific functionality I was looking for had not been implemented,
and work to make the tests pass by adding functionality to the three
methods. What I'm doing is maintaining a test suite that doubles as
living documentation of the current state of the system, and I do it
by not diverting from my coding practices. It's almost as if up-to-
date documentation is a free byproduct of TDD.

Take your choice: a shelf of unimplemented design becoming stale
like overproduced inventory, or working code like money in the bank.

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

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

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.