Agility Must Not Compromise Stability
Last week found me (briefly) in Minneapolis to
keynote the Agile 2006
International Conference that addressed many aspects of agile software development. In
some ways, the conference organizers made my task more difficult
by recognizing in the conference charter the need to look at more than
tools and methodologies: Their broad net encompassed "techniques and
technologies, attitudes and policies, research and experience, and the
management and development sides of agile software development." Heck,
how was I supposed to make any points for originality and insight when attitude,
were already right up there at the top of the conference home page?
I returned the favor, though, by making life a
little more difficult for the conference chairs as well. Every
conference organizer wishes that I could/would furnish an abstract of
my remarks, preferably the entire slide deck, months in advance so that
it can be incorporated in the conference proceedings. Whenever
possible, though, I like to live up to eWEEKs charter of delivering
breaking news by doing a talk that comes as close as possible to real-time
analysis of things that happened that day.
On this occasion, I settled for roughly a one-week lag: My talk began with a summary of the sad series of screw-ups that afflicted several high-profile code collections and IT stacks in just the 10-day time slice preceding my Monday morning remarks.
- July 14: "Software security provider McAfee revealed July 14 that it fixed a serious flaw in its enterprise security package Common Management Agent in January 2006 with a regular update (v3.5.5) and didnt even realize it."
- July 17: "The White House has set an early August deadline for government agencies to encrypt sensitive data. ... While encryption and other security technology can help, slipshod handling of data and equipment, poor training and the slow moving government bureaucracy are seen as the main causes of vulnerability."
- July 18: "Symantec researchers reported finding three different types of potential flaws in Vistas underlying software code. ... [T]he task of completely rewriting the sprawling code base without introducing any loopholes may be too much to expect from any vendor, said Oliver Friedrichs, director of emerging technologies at Symantec Security Response."
- July 18: "Database and server giant Oracle on July 17 shipped a quarterly critical patch update with fixes for a whopping 65 security vulnerabilities. The July CPU addresses flaws in several products and components, including the widely used Oracle Database, Oracle Application Server, Oracle Collaboration Suite and Oracle E-Business Suite. A total of 23 patches apply to the Redwood Shores, Calif., vendors flagship Oracle Database, most addressing flaws that could lead to SQL injection attacks."
If I walked into a Boy Scout summer camp and found this kind of ad hoc improvisation taking place,
Id ask, "Excuse me, but where is the adult supervision?" Pardon my
risk-averseness, but incidents and discoveries in the middle of
weeklong backpacks have sometimes given me
opportunities to point out that a planning process should not merely
debug your plans: It should debug
the process itself.
Im a confirmed believer in the values of agile
development, usually articulated as favoring:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Its crucial, though, to note the phrase that follows these statements of preference:
That is, while there is value in the
items on the right, we value the items on the left more.
In short, a preference to attend to individuals and interactions
does not mean that a team can neglect the definition and understanding
of processes and the selection and mastery of tools. A focus on
delivering working software does not mean that the code is its own
documentation. Gracious collaboration with the customer does not mean
doing work for which youre not being paid. Being prepared to
accommodate change is not an excuse for having no base-case plan.
The four stories that Ive listed above serve to illuminate critical
concerns when any processagile or otherwiseis to be trusted with
the production of enterprise code. No change should ever be made
without a complete understanding of what was happening before and what
will happen after. No system should ever be considered in a vacuum
without attention to the systems that interact with it and the people
who use it. No change to a system should exceed the ability of
designers and coders to comprehend its effects. No product timetable
should be allowed to put a code base far out ahead of the effort to
understand and maintain it.
Theres nothing wrong with being agile, but that word should be
understood to combine flexibility with precisionnot as a loosening of
constraints to the point of being formless and unsteady.
Tell me about the exercises that are testing your agility at email@example.com.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.