As I said a couple of months ago, you don't have to love or hate Extreme Programming. But you should respect it, because it's opened up the discussion on what a good software development project should feel like. Put simply, if your development practices are in extreme violation of XP, you've got some explaining to do. You may have very good reason why you're deviating from the XP ideal (like writing control programs for a nuclear sub, or a gamma knife). More likely, you may be dealing with a dysfunctional development process that no one had bothered to analyze.
Case in point: at $WORK, I'm still on that parser in Haskell. (Parsec rocks, btw.) The QA team wants incremental drops to test, as a means to show that we're making progress. That's fine. We're already on a 4-week development cycle, and that iteration length works well enough. (It's not ideal, but it's not Shangri-La, either.)
The problem is that there's a bunch of code to write and test, a requirement to do incremental development, and nothing connecting those two end points.
XP says we should have a planning game, user stories, and a customer that selects stories for each iteration. But we don't have an on-site customer co-located with the team. We have n layers of management between the developers and the (internal) customers. (Plus, we have multiple customers for this one project...the fun never ends.)
But we have a bug tracking system that tracks all bugs and feature requests. You can play all the semantic wordgames you want, but in reality, this is where user stories get stored; this is the same pile of stories that managers review weekly to dole out assignments. So it's not total chaos, just less efficient than the XP idea. Assuming these stories are in the tracking system, I can go over them with my boss(es) and pretend to play the planning game. That helps.
So, even in an XP-hostile workplace (like where I work), you can sneak in some XP ideas through the back door, and they do streamline the process.
Of course, there's a problem. There's always a problem.
Everyone is swamped, and as we all know, work flows downhill. So stories need to go into the bug database, and someone has to put them there. Since I'm the only developer working on the parser sub-project, that means it's down to me. I understand the problems, I understand the work, and I recognize the corner cases. Except that I don't have any requirements to work from.
Add that up, and I'm the one writing up user stories, without a full understanding of the ultimate requirements. Sure I can write up stories I can implement and even write up a suite of stories to describe the parser as I understand it. Hell, I can even invent requirements that my life easier! But that's not the software the customer wants.
The result is that I'm doing the customer's work for the customer. The XP dogma says categorically that you should not have members of the development team playing the "we know the customer's needs better than the customer does" card. If you choose to violate this practice, be prepared to defend yourself in front of the UN High Commisson on Preventing Improper Software Development Practices, because you are almost certainly doing something very wrong, and everything suffers as a result.
In other news, I noticed today that I hadn't updated my resume in over a year. Funny, that.
This is a lesson I learned during my first semester of co-oping with my employer. (Still my employer
I was assigned to add a "close code" feature to our trouble ticketing system. Close codes had three digits. The first indicated a close code category, and there were 100 possible close codes in each category. The close codes would be maintained in a separate database file (dBase IV
This led to a problem for me. What if the user entered a code that was not in the
And then when I submitted my work the recipient told me I was completely wrong. He pointed out that when the user entered an incorrect code the selected code might not be at all what they wanted, and that they might never realize. I had to go back and do it all over again, the way the user wanted.
I've seen every other programmer since me who came through this place make the same type of mistake. And I used to sit in on a lot of sessions where as a group we would consider such issues brought up by a programmer. (Sometimes the group was just me and one other guy.) And always I insisted that the only way to handle it was to ask the users. We can't possibly divine how they want every situation handled. We can't just make crap up.
Nowadays I work with more experienced people and I hear the same mantra repeated by others.
