But What IS Agile?
It's the right of every blogger (tech bloggers or not) to be opinionated. Every one has some strong opinion or bias towards something, there's no escaping it.
In the tech-blog world, there's always been one primary biased opinion (what I choose to call a religious war). Choice of programming language. Most prevalent (that I see) these days is VB.net vs C#. But if you're a .net programmer at all you lord it over java guys. And so on.
Other things can cause opinions to be cited too. A common one lately is Agile vs anything else.
I don't have a problem with Agile. I don't fully practice it, but I'm always open to reading about and trying more. I'm certainly not against it.
I am against the preaching, however. Besides purely instructional posts on what it is and how it works and what you do, all the rest I've seen can all be re-written to something like this:
'Agile r0x0rs. If u no use it, u r sux0rs'.
Yes, I've taken liberties and am exaggerating a tiny bit. This style of post is prevalent on many topics - especially the C# vs VB ones :) You can replace the word Agile from the above and swap in so many other terms, but the most common I've seen lately are 'TDD', 'Pairing', 'X' (where X is some piece of source control software), 'Y' (where Y is some piece of open source software) and 'RAD' (well, RAD as the bad thing, not the good). And all those other things that can fit in the same box.
What annoys me is that lack of information about what the hell each of these things actually is. Yes, I understand that you think Agile/TDD/whatever is the best way to do things. Yes, I understand that you love it. Yes, I know for the tenth frickin time that you think people who don't use it are idiots.
But how about telling me what it IS? Instead of pointing out all the problems with any other alternative, tell me what I need to do to do things your way. Don't tell me how much better things will go, how this thing will happen faster or that problem won't happen, tell me what I should DO.
What caused this little rant? Well, two things.
Today I read two different posts. They were on completely different subjects. There was really nothing wrong with either one (neither of them were a 'you sux0rs' post :). But both left me with questions that I'd really like answered. Please remember, I don't have a problem with either of these guys. I like what they do, I like what they write, neither they nor their posts are shit :)
Sam Gentile - No More VSS, Its Subversion.
My questions: What's visual unsafe? I did a google search, and I get nothing. (Yes, I have a brain, I know he's talking about Visual SourceSafe, but not everyone is as smart as me :) Why is it so bad? You've told me about a crash bug, but haven't given me a reason to consider switching. What version of VSS were you using? I know that with VS2005 they released a new version of VSS that is apparently a whole lot better than any of the previous versions - were you using this one or the old one? I'm certainly interested to know if there's problems in the new one, especially since I've heard no complaints about it until now. If it's the old one, did you consider switching the the new one? Why not? I read this post as not just blogging something that made you happy, but also a small attempt at convincing others to upgrade too. Why is subversion so much better? Sure, it apparently doesn't crash, but what are the other features that make it better?
Tim Weaver - Agile Development: Are you already half way there.
This was actually a really good post that I enjoyed reading. He gave a pretty good explanation of when waterfall is good, and when it can be bad. My problem is how he closed:
'Next time you are staring down a change request trying to figure out why your software development process always seems behind and never gets it 'right' the first time you should take a minute to consider the alternatives. Maybe the problem isn't with your process, but with the methodology you use. Agile development practices embrace the concept of constant change through the development cycle. Agile promotes using the inherent unknowns to drive a better product.'
That's fine - but how do I do what you say I need to do? What do I need to do to convert? How does Agile embrace the concept of constant change? You've left me hanging here dude :)
So often (and I know I'm guilty of it too) we write posts that are arguing for or against something, but don't complete the argument. We happily provide lots of examples of why the bad thing is bad. We happily spout off about how good life is with the good thing. But we so often leave out the crucial part (this is how to do the good thing, this is how to not do the bad thing, this is what can be done differently to improve X, etc).
Another good example was one time when I explained to someone how the source for our projects at work are stored in the source repository, and what pains we had with maintenance as a result (not going into specifics here). The response I got was 'Well, that's really bad, you should really review the way it's done and change to something that supports what you need better'. 'Sure', I say, 'what should we do?' . 'I don't know', is all I get back.
Any clown can see when something is wrong, but to be worthwhile, you have to be able to show what the solution to the problem actually is :)