Are your A+ engineers fire fighting all the time?

Scene: Fire everywhere

Action

For god’s sake, let’s just patch that code one more time and get it out of the door. We understand problem is deep but let’s just fix that one single case that’s showing up and ship it. Let’s just forget about that big hole in the way it’s architected for a moment. This mode of fixing is called fire fighting of knowledge industry.

Fire fighting by itself isn’t bad on certain occasions and it’s required as well to handle situations beyond control. But being trapped in it with the illusion of this is the best way to accomplish doesn’t seem right. What do you think? What are we losing?

Fire fighting is basically putting off the fire without worrying about its cause. What caused it? In the context of knowledge industry projects, sometimes fire can be accident but most often it’s result of short-term thinking. Trying to save a penny while losing the millions of dollars. When projects shift hand, it may be possible for current owner to fall in the trap of it’s not my fault. It’s the previous owner who did it. All I want to do is ensure there are no major hiccups while it’s in my hands.

Like a well-executed project is an art to be admired and enjoyed, a poorly executed project is like a haunted house. It will haunt you as long as you stay in it. Often there will be fire breakouts at critical junctures of project execution. When that happens, as owner of project first you want your best engineers to face it. Because this legacy code is customer deployed and it needs to be fixed asap.

While your best engineers start to put out the fire, they may come across next big fire hazard. It may be big one like an architectural flaw. It may be a flaw in thought process that was seeded right at the beginning of the project. Now it has grown to be a big tree. They come back and tell you it needs some refactoring to protect it from next fire incidence. Answer should not be to hide behind the priorities all the time. It needs to be faced and fixed some time.

Some may think there is no glory in fixing what was done in the past. No, fixing it is important. Let’s just continue with patchy solutions or let’s just get rid of the fire one more time will not fetch results in long run. Because by the end of every firefight your engineers will be tried which means for next fire hazard they will be less effective in dealing with it. More and more firefighting, less and less are the chances of engineers coming out of it. Get ready to loose few.

In background : New features coming in

While the best engineers are busy putting off the fire through another point patch in legacy code there are new requirements coming in. Engineers who are best suited to do the job are busy. Nothing waits for no one. What do you do? Get started with whoever is available. There is anyway glory in doing new things. Whoever is available may not be suited but it can’t wait. Time-to-market pressures are mounting. New project gets started and another horror is about to unfold. What could have been an opportunity to break this vicious cycle by clean fix gets transformed to another fire source.

Scene switch: New development and celebrations

The execution starts on new requirements. Execution just the way it going on in fixing issues. Its executed as another fire fighting exercise when it was not required. There is always need to do things faster. Faster does not mean poorer. But that’s what it gets inferred as. It’s thought as, doing job fast is a license to do a poor job.

An opportunity to set things right is thus wasted. Not only it’s wasted but also foundation for yet another endless set of problems is laid very quickly. Worst thing happens. Initial results on new feature implementation come in. Initial results are typically easy to achieve through shortcuts. They are celebrated. What’s not realized is, its celebration of death of quality. This death will give birth to evil ghosts called bugs. They will be born with wicked smile on their face. The new code gets shipped with the legacy code to customers.

Scene switch: Firefighters putting everything to get it under control

The best of your engineers slog day-in and day-out to put the fire off from the legacy code. Some of them cannot stand doing point patches. They will take it upon themselves to get it done right to best extent possible with their hands tied by timelines.

Consider problem of looking young by getting rid of grey hairs. Point fix is like plucking grey hairs visible one by one. Best of engineers who refuse to do that will at least try to cleanly paint it back with hair dye. Of course grey hairs will show up in a while but gives them some time to breathe.

What happens when they are about to breathe? Next fire breaks out in the new feature that was shipped recently. How do we manage it? It’s critical again. Whom can we entrust to put this fire off? I will not answer it. Figure it out.

Now what is the net effect of this? Your best engineers will remain in always fire fighting mode. Can we break this cycle? It’s possible. Say yes to faster execution but say NO to poor quality execution. We are not in time of Hitler where we are in grave dangers if we way NO. Saying yes to cutting corners and doing poor job is laying stones to your own tomb.

Do not take pride in fire fighting, if you are doing it all the time. Especially if the fire fighting is just to push the known problem to future Nth time. It’s like taking debt. If you keep drawing the debt soon you will be broke.

Fire fighting code fixing is illusion of making it less negative while making it more negative. Note only negative is quoted in the statement. There is no mention of positive. Your best engineers are stuck in a task where they almost have no chance for positive contribution. Let’s get them out.

How we can help to fix it?