Cutting Corners

I started at a company, full of hope and passion. I was told during interviews that they were looking for quality. I told them I do test driven development, and they were ecstatic to hear it. Within a month of working, I had already introduced a lot of change to improve the processes of the company. We were becoming more agile… well, actually being agile for a change. I was creating unit tests for all the code I wrote. We started deciding on a standard architecture to use. Things were going in a great direction.

Then we were at a sprint retrospective, and after the developers gave some estimates, everything went off track. A product manager, after hearing clarification for one of our estimates simply blurted out “I don’t care about all this testing and architecture stuff, I want new features, that is my highest priority.” In an instant, everyone except me started saying things like “well, we could skip the unit tests” or “well we could push rearchitecting this section.” I was flabbergasted by the change in attitude by the entire team.

The only reason a good developer would do bad work is if they are pressured by others. It is that simple. A good developer acknowledges that their code should be readable, reliable, reproducible and have unit tests. If any of these things are missing, it is because someone, somewhere, said “we need this in,” and thus the first corner was cut to make a deadline.

Soon, the cut corner is a standard of the project, and bugs start popping up everywhere. Cutting corners leads to much higher cost down the road. This is known as technical debt, and it is one of the biggest factors that will instantly destroy the success chances of a project. You want the least amount of technical debt possible, this will save the most money in the long term. Reducing technical debt is no easy task though. You will get a lot of push from management to cut corners because they think it is saving time and reducing cost. It inherently looks like a good idea. However, it is up to you, the development professional, to convince management of the correct path. Convince them that they do not want a Ferrari with a lawnmower engine.

The amount of time it takes for a bug to be found, reproduced, prioritized, scheduled for work, and then worked by a developer is staggering. Then, because this bug fix is suppose to go out before the deadline, the corners are cut again, and the whole process starts over. What if the developer caught it before it even left their local branch? All that time and all that money would be saved!