Agile isn’t low quality – a rebuttal to Mike Brunt
Mike Brunt quotes an email on his blog. The mail exposes a very negative view of agile. Although the email is not written by Mike, he is “posting this here because it states my reservations very well”. So address him directly because my experience with Agile over the last years is contrary to his experience.
1. Agile programming emphasizes programming over engineering. This results in software that does not have clean interfaces and is intertwined with other code. Of course, such code is difficult to maintain, debug, and replace. Expensive code bloat is the consequence.
The base fallacy here is that agile equals chaos. When looking at the clean code movement, which has grown out of agile, there is a lot of emphasis on good code. With heavy unit testing and refactoring, especially when you do TDD, code has clean interfaces, is easy to debug, maintain and replace. The code is light and agile
Many of these [bugs] are edge cases and not detectable by testing.
I think edge cases are especially found by testing. Agile emphasizes tight integration with testers and quality assurance. From my experience with agile this leads to more test-aware thinking with developers, leading to less bugs. The usage of static analysis tools like FindBugs or PMD is due to continuous integration and automation more accepted in agile circles which also results in higher quality.
An agile team, like a Scrum development team, has more control and more responsibility. They consider the code “their” code, which is often not the case with non-agile teams who are pushed to deadlines and low qualitiy.
Everywhere where I introduced Scrum or Agile code quality went up, architecture quality went up and bugs went down.
4. Agile programming deemphasizes designing performance into products.
Many agile teams have due to continuous integration and tight integration with QA and operations a clear grasp on performance. They include rigorous performance test into their builds and deployment strategies. Especially with continuous deployment designing and measuring performance is a must.
5. Agile programming never views a program or project as complete. There’s always room to tinker and add new levels of abstraction and modify the mechanics of a program. Expenses around programming become a sucking black hole.
To the contrary: Scrum emphasizes business value delivered, as does XP. No more tinkering, no exploding programming expenses. Some agile shops can clearly state to cost for each story point and calculate detailed ROI.
6. Agile programming is a model that rewards software churn. It’s a great model for building fiefdoms in a corporation and employ busy programmers; it’s terrible for corporations who want to produce maintainable stable quality products that will not incure high overheads.
Not sure if this is ironic and the post a satire. Nothing could be more far away from truth. Agile is about communication and cooperation. Scrum of Scrums coordinate teams to solve problems together for the future.
7. Agile programming deemphasizes quality. Deploying software that works after a fashion “rather than waiting for perfection” introduces a dangerous slippery slope. I doubt that many managers can define “acceptable imperfection.” Quality should be job one. Apple demonstrates that customers will pay a premium for well designed and implemented software.
As stated above, agile emphasizes quality on every level. Only agile teams have consistently a level of done agreement with jobs are only done when they are done done. This often includes acceptance tests, documentation, clean code, unit tests, release notes, refactoring, code reviews (reading from the Level of Done Agreement at the wall here).
8. Agile programming over emphasizes schedules. Production schedules and engineering requirements should be balanced by management.
As it’s true that iteration cycles often coincide with releases to shorten time to market, they are independent. In agile product managers can release each minute, each day, every two weeks or every six months, just as you see fit.
9. When there are many projects to add assorted features to a product, code become difficult to manage. Code merges and inconsistencies become difficult to manage so all the pieces play together. Merging code down can take several days given high rates of code churn. Costs associated with code management are not linear as the number of projects increase. I suspect that the cost function is exponential.
Merging sometimes get difficult. With agile or without agile. Many agile shops migrate to distributed version control systems like Git or Mercurial that aid tremendously with merging. Personally working in enviroment from 5 to 70 developers, I haven’t seen merges that “take several days”. Distributed version control helps with keeping costs down.
10. Agile programming uses customers as the test bed. Customers don’t appreciate being treated as guinea pigs.
Agile programming low bug-count, production ready code to customers. Due to late binding of requirements, active communication with customers and reviews customers get what they need and want. Not something that they assumed they needed some months ago. Due to “done done” customers are not used as “guinea pigs” contrary to traditional development with “alpha”, “beta” and “RC” releases.
11. The agile programming model creates an unstable expensive house of cards. The house of cards will eventually collapse despite efforts to keep it standing.
Hu?
I’ve been dabbling with agile since the beginning of XP and Kents first book. Later I introduced Agile in some companies and processes and became a Scrum Master. Nowhere where I’ve been I’ve seen those issues described. To the contrary, those issues were often rampant before the introduction of agile. This leads me to the conclusion that Mike never experienced agile, either by not doing agile or by falling into the traps of “let’s do agile” management, ScrumBut or Snake Oil selling consultants.
My experience is very positive, as is the experience of all developers I’ve asked and worked with. But perhaps its best to draw your own conclusion by listening to both sides.
You can leave a Reply here. Of course, you should follow me on twitter here.
A majority of it depends on the programmers and how closely you follow agile.
For the set of coders we have on our C++ project the agile process brought out the worst in them. They are OK at being told exactly what to do with a well thought out spec from a waterfall approach but have not done well with agile where they need to think of all the edge cases and account for them before they start coding.
Instead people are just coding away and hacking in fixes as QA brings up the issues later.
There is a VERY strong chance we are not using agile correctly. There was no training, just do it. Teams are too big, scope of work too large, terrible management.
No one has the same agile experience. Almost all patterns work very nicely when performed properly. My agile experience has not been pleasant but I don’t think agile is the problem, management and the programmers are.