So, normally I'm fully in the camp of planning out your work and then reviewing the plans for flaws, iterating on the plans until satisfied, and only then starting to cut the final code. But just this week I ran into an interesting situation.
The situation was this, we needed a way to get rough schedules for when multiple projects would be delivered and good estimate of month-by-month capacity to take on new work for a development organization of about 400 people. No problem, right? Just go out and buy one of the inumerable tools that vendors are more than willing to sell you, right?
Yeah, right. But we needed it by next week.
So I suggested we build a CAT (Cheap Ass Tool).
Would we ever ship this tool (like to customers)? No.
Would we be keeping this tool around and iterating on it until it is perfect? No.
Did we need to cover every use case and edge condition? Oh, hell no.
And that's how I found myself doing XP (well, really just pair programming kind of... read on).
Now, I didn't realize that it was XP at first. I mean, I was just sitting in my office with the project manager responsible for handing the final reports to the VPs and a director who would have to use the tool. They sat there and said things like, "We need to capture the project's priority." And I would nod and add priority to the database and add the "right thing" to the UI so you could edit it and report on it, etc.
We never bit off more than we could do right there and then. If something big like that came up, the project manager added it to a "parking lot" list that we'd address later. I should say up front that we spent a couple of days before this meeting to compare the spreadsheets that directors were using to do their own scheduling independently. So we had agreement in principle on what we were building.
Anyway, I'd add something and the director (looking over my shoulder) would say things like, "Didn't you want that to be an integer?" Or, "I think you're off by one in that loop." And that's the way we muddled along building a tool that about 20 or so people would end up using.
I find myself in situations like this one fairly often. I wouldn't want to build an OS this way. But for a "Cheap Ass Tool" it is really fast and effective. I suspect that it could have been made even more fast and effective if I knew a bit more about the formalism of XP.
A quick aside about the formalism of XP. I find it really ironic that agile methods (and XP in particular) tend to be really light on documentation, yet there are probably more books written on how to do it right than any other method. Yup. "Stay light, don't get bogged down with formalism and process. And here's a couple of books that will give you the formula to follow."
I mean, when exactly did you last see a book on the waterfall method? Try it. Go to Amazon and search books for "software extreme" and "software waterfall".
Anyway, back to my point...
To efficiently build any good CAT the end user and the person writing the tool must be partnered. They must be in the same room. That's because (obviously) there's no other way for the requirements of the user to get to the developer.
Hmm... maybe there really is a nice place for XP. I imagine that thousands of developers can't all be wrong (insert snide comment about any obsolete language or method here). I think that like Joel Spolsky points out, you've just got to realize upfront what kind of project you're working on.
I guess that for me, agile methods are alright for this kind of project.
No comments:
Post a Comment