Admitting shortcomingsPosted: March 30, 2011
Question: Why do we test software?
Answer: Because history tells us that there will be defects. If software always worked, we wouldn’t verify that it did.
Question: Why then, are there defects in software?
Answer: The current (known-to-man) process of developing software is defective.
We can pretend the process isn’t defective, but reality tells us otherwise. Its end result; software, is defective.
The agile manifesto
Individuals and interactions over processes and tools.
(processes and tools aren’t good enough)
Working software over comprehensive documentation.
(software can’t be accurately documented)
Customer collaboration over contract negotiation.
(we need to constantly query the customer for accurate information)
Responding to change over following a plan.
(the plan doesn’t work when the environment changes)
These rules are not the perfect way of developing software, though they could very well be the perfect answer(s) to dealing with the current reality of software development and customer requirements.
Dealing with uncertainty
An agile team knows that they don’t know. An agile team knows that no one knows. They are agile because they need to deal with not knowing.
An agile team is telling you:
“We know what to do this month, and will evaluate what to do next month depending on what next month looks like. Its weird, we know, but there you have it.”
“Until you figure out what you really need, we will remain agile so we can react to your changes.”
Sounds reactive? It is.
It is short-term thinking. It is the kind of short-term thinking that remains a total necessity in a changing environment. It is also expensive (wasteful) thinking.
In those statements you also find the a big reason why agile can be a hard sell. How far up in an organization can you sell the truth that the project really is out of control?
Iteration length and efficiency
The most efficient team is one developer writing code for herself. The second most efficient teamis a customer and a developer/designer pair-programming-requesting. Some development work is well suited for this, for example prototyping and GUI development.
This is about as short an iteration cycle you can get:
Customer says: Looks bad.
Customer says: Looks good.
What about really long iteration lengths? A six month iteration would need very detailed specs (description) to complete. It seems there exists some kind of correlation between iteration length and specification detail.
The manifesto tells us, “customer collaboration”. In the iteration cycle example above you have a 50% shared time investment between figuring out what to do, and doing it. So, in an iteration where you have four coders doing 40h/week each, say 640 hours a month, and given an iteration (sprint) length of four weeks, how much customer collaboration do you need?
We don’t know the answer to that question, but its significantly more than 4 hours of monthly sprint planning work. Given an iteration cycle time, there is an optimum ratio between figuring out what to do and doing it.
Most of the times it is grossly understated in favor of the doing. On average, teams need to spend more time discussing what to do with the customer, and spend less time writing code.
Waterfall is a more efficient way of developing software, provided there is accuracy in describing what should be done in the long-term. However, experience tells us otherwise; that we can’t predict the long-term.
Why? Why do we have to develop software in short increments?
Designing the logic circuits of a complete system is a near impossible task. Agile admits this, and prefers to develop empirically in short-term increments.
If you design for the long-term and then need to change something, the system becomes subject to the butterfly effect; in Chaos theory “sensitive dependence on initial conditions”. That means a small change in a complex system can have large effects elsewhere in the system. A change in requirements can have devastating effects on overall design.
Customer: “The print function doesn’t work”
Developer (shrugging): “You wanted us to change the date format in the product import, and that change seems to have broken the whole print function. Sorry.”
Customer: “Its okay. I got more $$$.”
No one can accurately predict the effect of any change. We can minimize the risk, but we can’t remove it.
|An agile team is in effect telling the customer: “If you’re gonna keep changing stuff, we’re gonna deal with it by developing in short-term steps.”
An agile team is also admitting to itself: “We don’t know how to design complex systems except by short empirical steps.”
If we remove complexity and change from the equation, there is no need for iterative development. We would be dealing with a closed system that could be designed, coded, and be done with. Unfortunately, complexity and change exists. What we want to do is minimize them, and use a method that minimizes their effects.
The waterfall model had a few faulty assumptions:
- The team can deal with any level of complexity
- Requirements never change
Since both statements are false we remain “stuck” with Agile as the so-far best (but yet imperfect) way of doing it.