Today there’s a brown bag lunch talking about “Agile Programming”. i’m not attending.
The problem i have with “agile programming” is not that it’s wrong. In fact, done right it’s a pretty good paradym for development. The problem is that like fad diets, it’s all too easy to get it wrong, particularly if you’re not paying close attention.
Looking over one of the many, many papers discussing Agile Development, i came across the following table of bullet points.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Can i just point out that two of those give me a screaming case of the willies? Ok, the whole thing gives me a case of the willies because to anyone not thinking, this isn’t about grading two project ideals, it’s about picking one tact over another. i guarantee you that folks will immediately focus all effort on the stuff on the left and squelch everything on the right.
Now, onto my willies. The first point i’ve problems with is the working software over documentation thing. Yeah, you can have too much documentation where you have no idea how something goes together. Suffice to say, i’ve also worked on a great many projects where there was no documentation, the folks behind the original implementation left the project/company/country and you’re left holding the bag. You have no idea why you need to pass “3” as the third parameter to the launch_missles() call or why, buried deep in some library the value is now “2”. You just have to build a project using that pile of undocumented, confusing crap.
Complete documentation is never the goal. Working documentation, however, is.
The other one that gives me the heebie-jeebies is the “Responding to Change” vs. “Following a Plan”. Yeah, you want to be able to incorporate changes dictated by a fast moving marketplace, and good design allows you to do that. Know what gets you good design? Having a clear understanding of what need you’re trying to fill. Not having that clear understanding gets you incredible feature creep and you wind up handing the customer a Pocket Fisherman that changes your car’s oil when what they wanted was a program to help them track their expenditures.
Yeah, i’ve been on my fair share of those projects too.
When i think “agile” and “scrum”, i’m generally reminded of the fact that small teams are fairly agile, and the goal of a scrum is for everyone to kick the ball away from everyone else while effectively going nowhere. It’s the folks outside of the scrum that actually do anything beyond that.
i know full well that folks are going to come back from this hour and a half intro talking about this great new methodology which will do little other than make things far worse than they already are. *groan*
