Summary
Absolutes are wrong. Usually.

When I hear or read something that doesn't make sense to me generally my first reaction is to consider what I'm missing. I tend to think most people are intelligent and well intentioned and have given some thought to what they're putting forward. This isn't, of course, always the case and I'm often times regrettably harsh with fools and idiots.

I think XP stuff is entirely worthwhile. I've experimented or lived with almost every fashionable process or methodology to come along in the last 20 years. Top down, structured, OOP (real OOP, not the crap people do now), UML (and all the bits that became UML), and now XP. I can tell you honestly I'm never going back. XP is good stuff. I think it's greatest value is that it forces the non-programming staff on or around a product to become realistic with respect to how systems actually have to be built. At least as far as we think we know how to build them. Nope, no more fat ridiculous, over burdened, uninformed process for me. I'm sold.

Ok there. I'm a considerate guy, not quick to judge, willing to listen to the other side, all around good human. So this is crap. There I said it. Crap. The worst kind. It sounds good. If you try to empirically verify it, it seems correct. But if you really do it, it starts to unravel. On the team I'm with now it looks to be at around 750,000 lines (that includes source, config files, build files, and so forth. Don't kid yourself, all of that is part of a system and all of it has to be maintained.). It's not that things are outright failing, but it sure seems to me that what might be called more traditional practices are becoming a little more prevalent, a little more valuable.

Now the crew I'm on is comprised entirely of frighteningly intelligent people (FIPs). (I mean frightening. If the aliens from Proxima ever invade I fully expect to squint into the ionized haze of what was our atmosphere waiting for the final assault and be like "Holy shit! That's Bob from work with them! I knew there was something about that guy.". Scary.) And even with an incredibly motivated and capable team it's becoming increasingly difficult and in some cases impossible to do things without thinking about what the impact on other code will be. And that, sorry, requires planning. So, lest I be accused of not being specific, here's some of the issues I have with not planning as put forth in the article.

First I think it's irresponsible. While I tend to agree that not planning too much about how you're going to build something is right, I think it's critically important to plan why you're going to build it the way you are. XP be damned, coupling, cohesion, transitive dependencies and all of the other properties of a survivable system still apply. If you are going sit on a stage and act like a guiding light you have to consider your audience. When I was cutting my coding teeth I was nothing so much as ready to type. This article, in that light, would give me justification for diving in and coding. The irresponsible bit then is not qualifying the statements made. It sounds a lot like a politician talking about a complex issue, not talking about the dirty bits because if people really understood how messy things were they'd never vote for the idea. Instead of a well schooled engineer who knows that building things always (yes, always, unless your building hello world. Event then people trade off stylistic issues) ends up being a set of compromises containing approximately 0 absolutes.

Second, it doesn't work. Nope, it doesn't. At least not in my world. It may be fine for a measly little 100k lines of system, but not for something moderately sized. Where I work everyone has permission to go anywhere in the system if they need to. Nobody has to ask if they can type in this file, or that package or whatever. If you need to do it, do it (Yes, I'm lucky). The problem is that every code bit has nuance. Not understanding that nuance but still typing can and, at least for me, does lead to all kinds of problems. That means that as I'm coding I have to plan on how I'm going to allow people to work with my code. Yes, plan. I have to make sure that there are reasonable points of derivation, the semantics are clear and can be groked with as little effort as possible. That's planning. And sometimes it takes time. As in stop typing for a while and stare off into space time.

Third there's this comment: "XP is so close, it's startling.". If there are keyboard gods, I would expect it's this sort of hubris would be most affirming. I can hear the Oh Really's already. I don't think I can recall a single popular idiom, language, process, whatever that wasn't presented except as "This is it". Maybe this is, but history is against it. As far as I can tell the silver bullet is always in the next chamber. Of course this is only discovered after you pull the trigger on the current one.

If the position presented had been a little more measured, a little more conservative my reaction would probably have been a little more measured, a little more conservative. Maybe not, but probably. All I know is that when I periodically look up and see the FIPs I work with staring into space, or sitting in front of a white board, I can only assume they are planning. And if they're planning, they probably need to plan. There's not a lot of wasted motion in this crew. I only hope they're not planning how nice the coast of California will look after San Francisco has been disintegrated.

Talk Back!

Have an opinion? Readers have already posted 4 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Rick Kitts adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger