Dec 082015

One thing that I find to be the most important aspect of my job (jobs), is to ensure that code quality doesn’t end up at the bottom of the priority totem pole. My current company has the look and feel of a young start up, despite the fact they have been around for nearly two decades now. I know what you are thinking, “That’s great!”. And guess what, you’re right! Rock star engineers get perks that rank and file don’t. Engineers run the company and the business tends to play pick up. We make money, we make great things, we play with new toys and tech.

When could this scenario be bad? While this question may spawn multiple posts in the future, the main event for this, dear reader, is to pick on code quality. Start ups do one thing, code. They code fast, they fail fast, they fix fast. They also leave a lot of bad code and hacks in place all over gods creation. No need to clean up, no need to follow best practices, get it working and get it out the door.

Why would a start up be like this? A big reason is money. Day 1, the company is losing money. Get a product, get it working, get it to customers so money comes in. At some point though, you reach some sustainability. Money is coming in, take some time, pay some technical debt.

This sounds easy, so what’s the big deal? Aside from legacy systems that take years to convert or refactor, there is a strange phenomena that tends to occur among developers, managers, directors, and architects. There is garbage code there, a little bit more wont’ hurt. The system is already slow in this portion, a bad design choice to get the work done faster won’t hurt much more. After months or years of this thinking, you end up with a system on the verge of technical bankruptcy.

Think it sounds crazy? Well, I am not the first one to suggest such things, but I haven’t run much on the topic in a while. I also want to take the time to draw some similarities between a couple different sources.

First, Netflix had something interesting to say that was indirectly related to this topic. In one of the presentations they made about their company culture, one of the chief officers made a comment that ‘We see a piece of garbage in the hall, we stop and pick it up’. Ok, paraphrased, but look at that sentence. He continued to describe this simple proverb as, each employee should feel the devotion to the company and have such a high sense of worth with respect to the company, that they are not just willing but will automatically engage in behavior that will maintain, if not better, the company on a daily basis. If you see a piece of garbage in the hallway, you pick it up. Not because someone expects it, not because you get a promotion, not even because you want to save the planet. Simply, because you love the place you work and want it to be good.

But that isn’t code, or is it? You see garbage code when you are making a surgical change to fix a defect. What do you do? You pick it up. You refactor the code on the spot if possible and write it up, test it, and ship it out. Is the piece of garbage code bigger than just a crumpled up piece of paper or wrapper? Is it more on the size of a small car? Then make a plan to clean it up. No one expects a developer to be superman and fix 1,000 lines of code when they see it sucks, but make a note of it. Make a bug, send an email. What ever you do, don’t turn a blind eye to it!

Netflix not good enough? Fine, let’s pull from outside the tech community. The broken window theory offers an interesting look at social phenomena that can easily apply to code quality on large development teams. The theory comes from the following example [wikipedia]

Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it's unoccupied, perhaps become squatters or light fires inside.

Or consider a pavement. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of refuse from take-out restaurants there or even break into cars.

Let’s change that story slightly. Consider a code base with a few unused methods, a few poorly written classes, a few sloppy database stored procedures, some bad table designs. If these aren’t fixed, then the people living with the code, will make more bad decisions. They will break more windows, they will add more sloppy code, they will accept database contention, they will take 50 lines to do 2 lines worth of work. Why should they care? The code is already littered with garbage, one more piece is never the problem, and they are on deadlines or have lives to get back to.

My challenge to myself is simple. Don’t add garbage to the pile. Note where the piles are when I see them. If I can’t change them on the spot, if they are too big to clean up alone, or I am just too busy, research and document the issue. Talk to a manager, a lead, someone more senior. Your the senior most person? Guess what, the people living in that code are looking to you. Fix the windows, pick up the wrappers, and please, for the love all good things in life, don’t just pretend it’s not there.

Sorry, the comment form is closed at this time.