"You Ain't Gonna Need It" - for me, one of the most completely misused pieces of jargon in the Agile lexicon.
More than anything else, this has been responsible for the misapprehension that agile processes are nothing more than hack-n-fix. The fact is, in many places it's not a misapprehension!
Don't fancy writing any technical documentation for the development you're doing?
"You Ain't Gonna Need It" - it's not like anyone ever reads spec's anyway
Don't feel like writing any user documentation?
"You Ain't Gonna Need It" - the functionality will probably change loads before you release it
Code comments?
"You Ain't Gonna Need It" - not with your brilliantly clear declarative coding style
Architectural design for complex system?
"You Ain't Gonna Need It" - make it do what it needs to do for the story you're on. We can't possibly know what we'll need in the future, so we'll just refactor it when we need to next year / sprint / week / tomorrow...?
Wellllll - yeah. But that's rubbish, isn't it? Sometimes you DO know what you're going to need.
What about the guy who's got to support the product or teach people how to use it?
What about the guy who's got to fix the bug or add the new feature in a year's time, who can't follow your brilliant style (and who will probably be you!)
What about the time you'll waste retro-fitting the architecture you could have got right in the first place?
Like any rule applied blindly and without thinking, YAGNI can get you into all sorts of trouble. Maybe more so.
Of course you shouldn't waste time writing complex technical documentation that no-one's ever going to read (although you should probably find out what it is they DO want, before doing nothing)
Of course you shouldn't comment your code like a first year under-grad and proudly tell everyone you're incrementing counter "i" by 1
And of course you shouldn't develop a powerful, flexible, reusable library for something you don't have any particular plans to do again
But you should at least think about what you do know.
Unless you don't need to do that either...
Thursday 3 February 2011
Tuesday 1 February 2011
What's in a Name?
In response to some comments in another interesting post on Stuart Lynn's blog I asked if we could stop using "Waterfall" as a generic term for "non-Agile" processes.
Guy Letts then asked me the rather obvious question via Twitter:
Here's the long-winded version!
Waterfall was originally (at least according to wikipedia <ahem> <poor research>) described by Dr. Winston W. Royce as an example of a deliberately flawed and broken system.
In my own university days, it was used as a teaching method to identify the stages of the software project life-cycle, but even then it was made clear that this wasn't a practical approach to use in the real world.
The problem with using the term "Waterfall" like this is that the flaws of the method are obvious. This invites the straw-man attack from those pushing an Agile agenda - "Waterfall is bad, therefore all similar approaches are also bad".
This is just as divisive and unproductive as the "it's all code-and-hack-and-fix" claims of the Agile-skeptics.
As it happens, and as I'll discuss in a future post, I think that the differences between the two approaches aren't as great as some people would have us believe. I think that applying generalised labels can create mind-sets which inform thinking and lead people to believe they have to take "sides". This is potentially harmful and benefits no-one but the guys with books to sell!
We should be able to look at all the tools available to use and choose the appropriate set for the job we have to do and the people who will be doing it.
That said, I started this, so...
A term that's commonly used in Agile circles is "Big Design Up-Front".
That's nice and descriptive, but has several drawbacks:
Again, there's an implicit assumption that Agile approaches are inherently better and that it's "wrong" to use anything else. That might be great if your audience is already in the club, but it's not an approach likely to win hearts and minds!
So why do I like the term "Traditional"?
What I really like is that it balances the positive and negative implications nicely:
Introducing new approaches, we need to be certain that we understand the value of existing practices and ensure we're not losing anything.
We need to be aware that logical arguments aren't effective for addressing opinions based on long experience or emotion.
And we need to understand that insulting people doesn't help!
Guy Letts then asked me the rather obvious question via Twitter:
Your suggestions for a better term...?The short answer, that I gave Guy, was "Traditional".
Here's the long-winded version!
Waterfall was originally (at least according to wikipedia <ahem> <poor research>) described by Dr. Winston W. Royce as an example of a deliberately flawed and broken system.
In my own university days, it was used as a teaching method to identify the stages of the software project life-cycle, but even then it was made clear that this wasn't a practical approach to use in the real world.
The problem with using the term "Waterfall" like this is that the flaws of the method are obvious. This invites the straw-man attack from those pushing an Agile agenda - "Waterfall is bad, therefore all similar approaches are also bad".
This is just as divisive and unproductive as the "it's all code-and-hack-and-fix" claims of the Agile-skeptics.
As it happens, and as I'll discuss in a future post, I think that the differences between the two approaches aren't as great as some people would have us believe. I think that applying generalised labels can create mind-sets which inform thinking and lead people to believe they have to take "sides". This is potentially harmful and benefits no-one but the guys with books to sell!
We should be able to look at all the tools available to use and choose the appropriate set for the job we have to do and the people who will be doing it.
That said, I started this, so...
A term that's commonly used in Agile circles is "Big Design Up-Front".
That's nice and descriptive, but has several drawbacks:
- It's a bit of a mouthful
- It tends to be used in scathing tones that imply all up-front design is wasteful. Which is ludicrous
- It abbreviates to "BDUF", which sounds vaguely insulting
Again, there's an implicit assumption that Agile approaches are inherently better and that it's "wrong" to use anything else. That might be great if your audience is already in the club, but it's not an approach likely to win hearts and minds!
So why do I like the term "Traditional"?
What I really like is that it balances the positive and negative implications nicely:
- It recognises that there may be newer alternatives that may have advantages
- It doesn't imply an assumption that newer is always better. These methods have been used successfully for many years; they have been refined over time and many people are attached to them.
Introducing new approaches, we need to be certain that we understand the value of existing practices and ensure we're not losing anything.
We need to be aware that logical arguments aren't effective for addressing opinions based on long experience or emotion.
And we need to understand that insulting people doesn't help!
Agile Consultants
Time for a bit of disclosure - before it becomes too obvious from my other posts:
I've had some poor experiences of "Agile Consultants"
Don't get me wrong, there are some good people out there - guys who can come in and genuinely have a positive impact on your business.
The problem is the other kind - the kind who:
I've had some poor experiences of "Agile Consultants"
Don't get me wrong, there are some good people out there - guys who can come in and genuinely have a positive impact on your business.
The problem is the other kind - the kind who:
- is a hacker who's never delivered a large-scale solution
- who sees process discussions as an argument to be won
- who can convince senior management to part with a pile of cash then blame the failure on the development team who "just don't get it"
- who was in the right place at the right time, and wrote his/her meal-ticket because of who they were standing next to
Yes, I'm being overly cynical - but there are a lot of consultants on the band-wagon and there are people like this out there. If you are looking to bring someone in, do your research properly:
- Talk to their previous clients
- Find out what their ROI was 6 months later... 2 years later
- Talk to the developers and find out what they thought
- And be wary of promises that sound too good to be true...
And if you think I've been too cynical, then read this anonymous, satirical, blog written by someone (not me) with similar experiences and a better sense of comic timing!
Subscribe to:
Posts (Atom)