Totally gay blog post
Sometimes, the word stupid is not enough. Today I learned some of the terminology used to describe parts of Agile software development. Agile is a popular “methodology” adopted by software companies as an alternative to admitting that they are incapable of putting together a development process that works. It is essentially the same as having no process whatsoever, but with the subtle difference that your CEO can tell investors and large customers that you “have a process.” And he’ll be taken seriously.
Agile: a flowery way to say Out Of Control
Agile allows developers to maintain the illusion of software process, while allowing developers to do whatever they want with no process or plan. How? Agile accomplishes this through the use of Flowery Terms. Each step in software development at a company with no process is documented and given a Flowery Name.
For example, when collecting product requirements, a developer who follows a process would normally document Use Cases. Agile’s Flowery Name for this is “User Stories.” I am not making this up! And the important difference between Use Cases and User Stories is that with Agile you are encouraged to be half-assed and never finish them. Well, officially, you are encouraged to do “just enough” and come back and “finish them later,” but we all know that this never happens. With Agile, we do things just like we always have in the past, except that now it’s our process, and it has an investor-friendly name.
So I guess I’ve always been Agile. And here I thought that we were “winging it” at some of those companies!
Surely there is a better way to say this
But enough about Agile. Where I work, we have processes and we follow them. They are not overly burdensome and we get a lot of work done. I’ll be damned before I use the name “User Stories” to describe how we define requirements. That term is completely, it’s totally… something.
I can only describe “User Stories” in one way: that name is Totally Gay. And now I have a problem. Because I’m not a homophobe–but I feel about “User Stories” the same way a homophobe feels about gays. Isn’t there a non-bigoted word that means the same thing? “Stupid” is not a good substitute–it isn’t even part of my definition. Another word that implies all these things at once:
- lame
- laughable
- contemptible, even
- slightly offensive
The phrase “laughably lame” works, but “laughably” is intellectual and “lame” is anti-intellectual, resulting in a phrase that nobody will use and is hard to say.
I want a simple phrase that means the same thing as “totally gay”, but which doesn’t imply that I’m a complete douche. (If you use the phrase “totally gay” without apologizing, you are a douche.) Google turns up nothing.
I’m wasting your time
This should all be unnecessary. This whole blog post would fit in one Tweet if I could just say “Agile software development is totally gay” in a way that wasn’t, you know, totally gay…or something.
January 14th, 2012 at 12:47 am
We’ve used Agile at the company where I work for well over a year. The key difference between Agile and traditional software development methods is that Agile is feature-driven, as opposed to design-driven.
Agile certainly gives the illusion of progress – but there are many downsides. First, is the huge amount of code refactoring going on during each sprint (e.g., a time-boxed development interval). This is because features are implemented without taking into account how future-features will be implemented. A new feature may require substantial rewrites of other features that have been painstakingly developed, tested, and integrated.
In addition, when you implement a feature – the developer often has to interact across multiple project teams because of the overall lack of system modularity – and these interactions are slow, and highly error-prone.
Agile – which generating a lot of code is short order, creates an unstable, non-modular system – a maintenance nightmare. What you end up with is a creaky, buggy prototype – but hey, it’s all about the demo – and a continuous showing of progress. In our case, there is some design-work, but it’s always “just-in-time” design – and the scope of the design effort is so limited that it does not mitigate the aforementioned downsides.
I’m old school: Have an idea, develop an architecture, define the modules, define the interfaces to those modules, document the interfaces, use-cases, work-flows, exception-cases, implement the modules (which, by-the-way, can be done in parallel without a lot of dependencies), unit test each module, integrate the system, develop system tests, harden the system, ship product. It works well – as long as requirements don’t change too much during development.
In Agile, requirements (user stories) can change at any time – because it’s just a feature set, and not a design. So managers who cannot make up their mind – or more likely, loose interest in some features, and want some different feature – love Agile. To me Agile serves managers who really don’t understand the proper way to do software development – because it lets them do what they want – which is, to change their mind as often they want to.
January 16th, 2012 at 11:14 am
“Agile is feature-driven, as opposed to design-driven”
Funny. It sounds like this somehow implies that my non-Agile design is not feature-driven. :)
It seems to me that *any* methodology will work as long as the requirements don’t shift too much.
January 17th, 2012 at 8:15 pm
“It seems to me that *any* methodology will work as long as the requirements don’t shift too much.”
This is true. Agile works better when the features are well-known in advance – and don’t change all that much. But the thing is – that is not how Agile is typically used.
Another thing – you get used to what you are doing – and after doing Agile for awhile – all that daily code refactoring just seems more-or-less the normal way of doing things. The pay is the same.
I know after a few years, something else will come along – and the faults of Agile will be highligted so as to justify the newer method.
January 18th, 2012 at 9:58 am
Now that I look back on my own comment, I remember that the whole POINT of requirements documentation is to prevent the design from shifting mid-process, and documenting areas where you expect it to change, etc. :)