Opinion: A rash of problems with code base maintenance signals widespread process deficiencies.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,
policy
and management
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 process—agile or otherwise—is 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 precision—not as a loosening of
constraints to the point of being formless and unsteady.
Tell me about the exercises that are testing your agility at peter_coffee@ziffdavis.com.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
Application Development 
