eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.