I know that you, dear reader, have come to expect a certain level of sophistication and journalistic integrity when it comes to my monthly pontifications: A gloss of civility, a certain level of refinement, and an even airing of all sides of an issue. Thus, on those very rare occasions when I have a personal opinion to present, I feel the need to make my viewpoint on the issue under discussion extremely clear. And so it is for today’s topic: Agile software development methodology.
Let me start, then, by clearly, dispassionately, and logically describing my point of view:
Agile software development methodology sucks ass. Big time. Totally. 100%. Entirely.
Gosh, I hope I’ve stated that clearly enough.
Let me explain further: I have never, not once, not ever, participated in, seen, or even heard of a project in which Agile works better than any well-organized alternative. Agile is without question the refuge of those with small minds, poor writing skills, and extremely high-levels of tolerance for incomplete functionality that’s written in a way that’s “good enough” to pass whatever tests happen to exist.
Just to make sure that you understand that I mean to slag the entire, wide-ranging, genre that is Agile, I specifically mean to include Agile permutations like Scrum. Basically, I mean to include any software development methodology that relies on references to barnyard animals, where you stand-up to have meetings, or where you’re supposed to account for what you’re doing in units of, like, 45 minutes.
My major objections to Agile come from what I view as the unmitigated stupidity of its three most important tenets:
- A maniacal emphasis on “just getting something working” as opposed to thinking something through, designing how it should work, and getting something working correctly.
- Requiring detailed estimates of how long it’s going to take to implement some piece of functionality.
- An insane reliance on – and limitation to implementing features for – user stories (AKA scenarios), which yield fragmented feature sets as opposed to designing for well-reasoned comprehensive functionality.
For the life of me, I do not understand why I would ever want to write code for a complex facility before I have had the chance to design that facility and consider how it will interact with everything else in its environment. For sure, managers like it. They think designing things is a waste of time anyhow. This reminds me of clients who tell me to “just write some code” to do so-and-so. I work in kernel-mode, boys. I often work on complex pieces of larger systems. It doesn’t make a lot of sense to just “write some code” that’s “good enough” – when you do that, you get code that doesn’t handle corner cases, doesn’t work or play well with others, and is generally ill-conceived.
But Agile is all about “just writing code.” System architecture? Design? In Agile, that’s not in the plan. What’s in the plan is “code it up and see how it works” and “you can fix it in the next sprint.” That’s hosed. It’s a waste of time. And while I’m all about “plan to write one to throw away”, I sorta think that the word “plan” is important there.
Ever build a house? You don’t start building a house before the architect draws-up the plans. It’s the planning phase where you get to consider costs, trade-offs, and how one part of the house will relate to and work with other parts. You probably don’t want the garage to open onto the living room. Or maybe you do. But at least you need to think about it. And, having thought it through, you begin building.
Now, wait… wait… wait. Before you go all “that’s not flexible” and start screaming “waterfall, waterfall, waterfall” on me: As you progress through your building project, there will be problems, issues, and changes. You need to deal with those. You go back to the plans, you discuss what’s changed, and you retro-fit those changes to the plan. Then you resume building.
And so it should be in software engineering. It is vital that you at least design what you want to build, even if this means your manager-troid will have to wait an extra week to see some demo he won’t understand anyways. And if you’re designing a larger system with multiple interconnected sub-parts, you must define an architecture for that system. As you progress through your architecture, design, and implementation, at any point you can revise the plan, revisit what you’re trying to do, and take the time to think through (and document) the consequences of your changes.
And, that brings me to the second thing that makes Agile suck so badly: The whole “estimation” process. Every time somebody insists that I estimate how long it’s going to take me to implement some particular functionality, and in Agile it’s not uncommon to have to do these estimates with great precision, I realize I am dealing with an idiot. Worse, I realize that I am being asked to lie. And I don’t like lying. Well, at least not to most people and not usually very much.
Why is estimating software development time so hard? Duh! Truthfully, I can’t even estimate with good precision how long it’ll take me to go to store and get a case of beer. There could be construction, a traffic jam, the store might be out of the beer I want, I could get a flat tire, I might get distracted and decide I need to get a sandwich before I return home. If I can’t estimate how long it’ll take me buy a case of beer, how the hell can I possibly estimate how long it’s going to take me to implement some functionality that nobody’s ever done before, for some device that’s just had new silicon fabbed? The whole concept is ludicrous, not to mention insulting.
And don’t even get me started on Planning Poker. If you like being treated like a mentally defective 6 year old, you will seriously like Planning Poker. If you haven’t heard of Planning Poker, just pray that your manager doesn’t discover it. It’s the kind of thing manager-troids love, because “it’s fun for everybody” and leads to “really good estimates.”
On the Agile projects I’ve worked on, the planning process is just a big “everyone’s in on it but the boss” joke:
Boss man: You, copiously large engineering unit over there, how long will it take you to create the huzzy-bub for the what’s-a-ma-whosits?
Me: Well, boss man, I thought long and hard about this, and after consulting with my team members and the folks in test, I’m confident I can have it done mid-way through Sprint 832.
Boss man: Well done! That’s what I like, a compliant and focused, if slightly overweight, engineering unit. Do you have milestones for that?
Me: Oh, yes, boss man. I do. I definitely do! It’ll take 2 days to modify the frobnitz, 3 days to code-up the blortz-fart, 2 days to test the blortz-fart and frobnitz together, 2 days to modify the frazzle-blow, oh… no need to bore you with the details, great one… I’ll just put it all in our Online Agile Super Planner, oh mighty master.
Boss man: Well done! I like specific milestones. Why can’t the rest of you give me nice, clear, specific milestones like the fat guy over there with the ponytail. Whatever his name is.
Of course, I’d written all the code already, during the previous sprint. I just hadn’t checked it in. So, during Spring 832, I could update the Online Agile Super Planner to indicate that I hit all my milestones, while I worked on whatever it was I wanted to commit for the next sprint.
Don’t try to tell me you do anything different, cuz I know that’s what you do. Everyone I know works this way. When you know what you want to build, you just build it. Then, having already built it, you provide astoundingly precise estimates for when you’ll have it done. Then you check in what you’ve already written according to the estimates you provided. Ka-Ching! Goals and objectives: MET. Conformance to process: PERFECT. Ability to estimate: AWESOME. Ability to deliver: EPIC. Now give me my bonus.
And that leads me to the final Agile precept that fries my potato: User Stories. Every time I hear somebody say “I’ve entered that as a user story” I want to puke. Why? User stories are just that: Stories. They’re data. They’re not wisdom from the ages. And, the way I see them used in most cases, they’re not even necessarily fully representative of what the majority of users want or need to do. When your development process is focused entirely on implementing functionality based on a handful of user stories, you more often than not end up with a random, inconsistent, poorly integrated, mess.
User stories are the software equivalent of task based documentation – another stoopid fad that I truly despise. But, you know, manager-troids love task-based documentation for the same reasons they love user stories for software development: It’s easy to understand, it’s easy to demonstrate that it’s correct (just follow the steps and see if they work), and you can get an idiot to do it. The problem? It doesn’t consider anything that’s not specifically required for you to achieve the task. For example, you can write a document chapter entitled “How to Peel an Onion” that describes the process in detail. It will cover all the steps. But, on finishing the chapter, the reader hasn’t learned anything about onions, peeling, or anything else. They’ve just learned how to peel an onion, and even then only under the conditions that the chapter contemplates, using the steps the chapter prescribes.
And so it is for user stories. Let’s say you get a couple of user stories like “Bob is a church-going motorcycle rider that needs to store digital copies of his ‘special’ magazines in encrypted form on his flash drive” and “Hector served with Che Guevara in Bolivia and needs a safe place to store his secret communications.” You code to these particular stories. No, you don’t get a chance to think through the overall experience for any user. This is Agile software development. You don’t get to think. You’re not allowed to design. You’re allowed to “get some code working” so you can try things out. And that code just needs to meet the user stories, and pass the tests that were so lovingly crafted and stored with those stories. Anything else? Well, that’s for next sprint.
So, in Agile what you get are ridiculously incomplete requirements, driving a development process that emphasizes sloppy implementation over design, that’s tracked using a long list of bogus and irrelevant milestones. The only thing that’s left to wonder about is why everybody doesn’t think Agile development sucks ass.
Peter Pontificates is a regular opinion column by OSR consulting partner, Peter Viscarola. Peter doesn’t care if you agree or disagree, but you do have the opportunity to respond and perhaps even see your comments or a rebuttal in a future issue. Send your own comments, rants or distortions of fact to: PeterPont@osr.com.
OSR Open Systems Resources, Inc.