Thinking Of Agile - XP Please Read This first
Posted by Mike Brunt at 2:31 PM
111 comments - Categories: .NET | CloudComputing | ColdFusion | JRun-J2EE
This is a verbatim email from the Guerrilla Capacity Planning mail list. I am posting this here because it states my reservations very well and I advise any thinking of Agile or XP or frustrated with the results of either to read this.
" I was at a company that still embraced the agile software model. I have a negative impression of agile development for a number of reasons.
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.
2. Agile programming emphasizes coding. The more code that a programmer produces, the more productive he/she is. This emphasis on production introduces unnecessary bugs. Studies show that for every 100 lines of code written by a good programmer, 2.7 to 3.2 bugs are introduced. Many of these are edge cases and not detectable by testing. The more code that is written, the more bugs that programmers introduce unless they perform comprehensive function and unit testing; unfortunately, this is a skill that is rarely taught. The consequences are bizarre intermittent failures, Heissenbugs, and unpredictable interactions and other undesirable side-effects.
3. Agile programming is inappropriate for product development where companies will live with an architecture for a long time. It's better to engineer an architecture and design clean interfaces than to crank out code that will soon become problematic. The agile model may be appropriate for making incremental changes to mature software products.
4. Agile programming deemphasizes designing performance into products. After all, the packages and libraries can be replaced in the future. The problem is that the future never comes unless there is a crisis.
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.
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 incur high
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.
8. Agile programming over emphasizes schedules. Production schedules and engineering requirements should be balanced by management.
9. When there are many projects to add asssorted 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.
10. Agile programming uses customers as the test bed. Customers don't appreciate being treated as guinea pigs.
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."