Why Your Software Project is Late (Part 2)

Instead of rehashing the basics of project management, I want to expose some unexpected things that most software buyers or business team leads won't be aware of because they don't have my unique perspective. I've had a bizarre career path—believe me, I know—but all of the roles I've had look at software with a truly unique perspective, and that is something most people who spend even their entire lives in the industry rarely have the opportunity to experience.

This is a continuation of last week's piece: Why Your Software Project is Late (Part 1)

Rewriting Code that Already Works

Imagine you have a project with five modules. The modules are evenly spaced in time and effort (at least from the team's estimation at project launch). It should then take five units of time to complete the five modules.

The developers build the first module on time and on budget. Everyone is happy. Everything is going great.

However, by the time the second module is delivered, the schedule starting to slip. When building Module 2, the developers realized that there was a much better way to build Module 1, and so they went back and rebuilt Module 1—not because it was broken—just because it could be done much more elegantly in light of what they now know about Module 2.

This pattern repeats itself again for Module 3. The developers realize both Module 1 and Module 2 could be built much better in light of what they now know about Module 3, and so they re-build Module 1 and Module 2 while building Module 3.

I call this asymptotically approaching zero forward progress.

Developers are often obsessed with quality. You may not know it by looking at the user interface, but behind the scenes, they are trying to make sure that their naming conventions are precise, logical, and universally consistent. They obsess over making their class inheritances non-redundant. They want to make sure there are no hard-coded values buried anywhere in the methods. The list of little things that worry them goes on and on.

Rewiring a House that Already Works

Think about the wiring in your house. The house is completed and you're about to move in. Your electrical panel looks like this:

It works. It provides power to your house, all the lights turn on, and it's not going to catch fire. But it's also not very pretty—which doesn't really matter, of course, because it's in the unfinished part of your basement. None of your guests will ever see it. But let's say it bothered your electrician so much he went back and pulled all the wires out of your house and re-ran them so that it looks like this:

Now you have perfectly spaced, color-coded wires that don't cross and have similar radius bends, probably with descriptive labels following a consistent nomenclature and hierarchy. This is awesome for sure, but it forced you to re-sheetrock all your walls, re-install and re-paint your trim, and refinish your beautiful hardwood floors.

Sometimes it's a good thing

Would you be pleased with your electrician? Maybe. If you really wanted this electrical panel to look super-nice and it was so important to you that you were willing to tear out all the other things in the house, then yes you will probably be pleased with the electrician's work.

Let me be clear: it's not wrong to be obsessed with code quality and constantly improving the little things hidden in the depths of your product. Steve Jobs famously obsessed with what the wires looked like on the circuit panels inside of sealed phones.

There Ain't No Such Thing As A Free Lunch (TANSTAAFL)

However, Steve Jobs was the boss. He had a very specific reason for wanting these things, and he was willing to accept the consequences. Apple had a brand image to maintain, and endless obsession over the tiniest little details that no one would ever see played into the brand. Note also though that Apple was often years behind schedule.

So imagine if the electrician did all of this without your knowing, without your input, and he did it every four weeks over and over again as your house was running desperately over budget. This happens all the time on software projects, and it ties back to my article last week on Shadow Requirements. Code quality is a shadow requirement. After delivering 57 projects in my career, I have never once heard a software buyer specify that all the methods in all the classes of their application follow the same precise naming convention.

Constantly rewriting code that already works might be causing your project to fall desperately behind schedule, with massive negative repercussions to your bottom line, your reputation, and your customers.

Not the Same as Quality Control

I also want to take a moment and say this is absolutely not the same thing as quality control. If there is a bug in the code that causes other modules to not function properly, that counts as code that does not work—not code that already works. If the user interface is confusing or not pretty enough to meet their needs or running too slowly, that all falls into code that does not work and needs to be fixed.

Maintainability is Not a Valid Reason

A lot of people will also claim that code needs to be cleaned for the purposes of future maintenance. The problem with that logic is the following: The first time you solve a problem you tend to think very linearly... step by step. However, by the fifth time you've solved the problem, having come at it from ten different directions with a ton of perspective, and with an eye for a supremely elegant solution, you tend to solve in a fancy way that is much more difficult for someone to come along later and understand quickly. Sometimes making it more elegant makes it less maintainable.

Sometimes it's Intentional

I have discussed this very subject with a developer only to have them say:

"Well, I know from experience that if we rush through to the end, without cleaning up the code as we go along, the project will end and we won't get a chance to go back and clean it up. We will just move on to the next project."

This individual didn't realize if the project fell behind we could all lose our jobs. He also didn't appreciate that the customer couldn't care less what the code looked like. As long as it functioned properly, the customer would be happy.

Sometimes it's Pathological

If you recall from my article on How To Deal With a Problem Employee, I have a five-step process for making sure an employee knows what their problem behaviors are and is given a real chance to fix those behaviors before resorting to termination.

Rewriting code that already works is sometimes a sign of Obsessive Compulsive Disorder (OCD). They literally cannot stop themselves from doing it. If you were to stand over them at work they would just do it at home. It's incredible and saddening to watch. This is one of the few things I have had to fire employees for because they will do it over and over again even after they have been warned not to.

A Better Way

What I focus on is getting to the project finish line as quickly as possible. When we are working on Module 2 and think of a better way to rebuild Module 1, we write down our thoughts so we don't forget, but we keep working on Module 2. When the project is complete, we can then go back and rewrite every module only once.

This takes less time than having to constantly rewrite modules over and over again. The team will have more clarity over what really matters and what doesn't at the end of the project.

However, we might also decide that it works well enough and there are other projects that need to be worked on next instead. Or maybe the team can even take a well-earned vacation since they just finished ahead of schedule and under budget.