The Release Rush

Two blog posts (The Crunch Mode Paradox – Turning Superstars Average and Exception Handling in Software) really reminded me of something this past week.

Fortunately at YouDevise, we have a very strict No Death March policy. Working 40 hour weeks is company policy. (You don’t want to see Squirrel angry, do you?) But, in our past, we have seen the Death March’s sneaky cousin, the Rushed Out Feature/Bugfix.

The warnings signs are often a reasonable (or unreasonable) “customer deadline” coupled with too much other “high priority” work. The developer will usually get the feature assigned to them too late to do the correct thing and spend the time on it that it needs.

Now, all of our developers are smart guys, and they will usually figure out a way to squeeze the feature out in time, but it will always be at the cost of rotting the code around it. Now, being a smart guy, the developer has good intentions and plans to fix it later. Inevitably though, given that the feature is now “complete”, all of the refactoring, testing, and clean-up gets lost in the priorities shuffle.

We need to be diligent and focus on doing things correctly and not simply fast. All of us have stories of leftover code that was just slopped together to get it out the door quickly. Then, many months later, the bugs surface, and we end up spending many times more effort to spelunk the code, figure it out, and find a fix that doesn’t cause more problems. That doesn’t even cover the time spent needing to fix the original technical debt needed to refactor, test, and clean up the code.

We need to be diligent to make completing features (and bugfixes) correctly our first priority. Trust me, if we make all of our code changes correct, making code changes quickly will usually follow right behind it.