Starting Over

Knowing when to say when the secret to project success

I'm starting to get that uneasy feeling again.

If you've ever doneo software development, you'll understand that it's not like building a bridge. When you build a bridge, you know everything about bridge-building and what kind of bridge you are building. With detailed enough plans, you can predict down to the individual bolt how much material you are going to use. You can predict to the hour how much labor is required.

Of course, there is always slack. People get sick, materials show up with varying levels of qualtiy, the weather drags in and slows everything down. But there's a lot you can know going in to a bridge-building effort.

The same is not true of building software.

Or maybe a better way to put it is, "software not only has this variability to a much greater degeree, software also actually creats the problem space as it is deployed"

Pretty big words, eh? Basically you don't know everything about what you are building until you are done. With a bridge, hey, everybody knows what that is. But with an ERP system? Or a CRM system? Sure, these words have some general meanings that people accept, but I can guarantee you when companies say they want a CRM solution, they couled mean just about anything. That's why Mahan Khalsa recommends in his book "Let's Get Real or Let's not Play" that you never just take a customer's word for what they want or need. In the techology sector, the terms are fairly meaningless. You have to probe to figure out where the actual pain is.

To make things worse, people really don't know what they need until they are done getting it. This drives us technical folks crazy, but that's life in the real world. People know they need some stuff, you give it to them, and then they know more about other stuff they need. As you build the "bridge", you're also creating the definition of the word "bridge", which isn't true in the construction business.

So I'm coding my new project, batBack, and I'm getting an uneasy feeling about the way some of the code is working. Nothing's really broken -- oh there are a few things. Like sometimes the links to the articles are incorrect. Using a big honking XML file for blog engine configuration seems kind of crazy as the file gets larger and larger. I've almost completely abstracted out a new way for DOM manipulation, but it still has some logical holes.

The trick is knowing when to say when. When to deal yourslef a new hand. At the simple level, we call this "refactoring". At the project or program level, it really doesn't have a term. You need to throw away some pieces and replace them with better pieces. Sometimes this is a little thing, but most often it's a big deal. It means you are gutting some central part or parts to make them work better.

Non-technical people hate this. Just when they feel like they are getting closer to the goal, you change the rules of the game. Risk-adverse project managers also go crazy when you explain that you need to "refactor" major parts of the project.

But that's short-term thinking. Sometimes short-term thinking is good, sometimes it is not. It's not something I can explain in quantifiable terms, but it is something you learn with time, I think. So I'm getting this feeling it is time to do some refactoring, but I'm trying to fight it.

But no matter what, I know that the moment of refactoring is coming, like it or not.