How not to cause a disaster in your code

Recently, I’ve participated in an interesting talk about a bug policy. It was basically related to an approach of handling bugs in a software house.

At the very beginning, I felt it’s gonna be one of these unnecessary discussions because the problem seems to be quite obvious. It’s simple, right? You see a bug, you fix it. Alternatively you create a Trello/Jira/Asana task if you are extremely busy at the moment.

Unfortunately, it turned out very quickly that what was pretty clear in my opinion, was not so apparent to others.

Leave this world better than you found it

I have a personality that I fix things when I see them broken. When I see a litter and a bin nearby I pick the litter up and drop it there. When I’m in the kitchen, and I find a stain, I clean it up regardless of who have made the mess.

The Boy Scouts have a rule:

Always leave the campground cleaner than you found it.

The same should happen to us when we open somebody's code. No matter who the original author was, what if we always made some effort to improve the module? What would be the result?

Whenever there’s a code needed refactoring, and this refactoring will indeed happen, our systems will gradually get better as they evolve.

I don’t think this rule is too much to ask. You don’t have to make every module perfect before you check it in. You simply have to make it a little bit better than when you checked it out. Of course, this means that any code you add to a module must be clean. It also means that you clean up at least one other thing before you check the module back in. You might simply improve the name of one variable, or split one long function into two smaller functions. You might break a circular dependency, or add an interface to decouple policy from detail.

Frankly, this just sounds like a common decency to me — like washing your hands after you use the restroom or putting your trash into the bin instead of dropping it on the floor. Indeed, the act of leaving a mess in the code should be as socially unacceptable as littering. It should be something that just isn’t done.

Broken Window rule

Don’t leave bad designs, wrong decisions, or poor code unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then schedule it, make a task in your ticketing system. Perhaps you can comment out the offending code, or display a Not Implemented message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation.

Why does software decay happen so quickly? Why don’t developers follow good programming practices to keep the design and code clean? One way to explain this phenomenon is through the broken window theory.

A Stanford psychologist reported some experiment testing the broken-window theory. He parked two comparable cars on a street. One of them didn’t have license plates. It was attacked by vandals within ten minutes of its “abandonment.” The first to arrive were a family — father, mother, and young son — who removed the radiator and battery. Within twenty-four hours, virtually everything of value had been removed. Then random destruction began — windows were smashed, parts torn off, upholstery ripped. Children began to use the car as a playground. The second car sat untouched for more than a week. Then psychologist smashed part of it with a sledgehammer. Soon, within a few hours, the car had been turned upside down and utterly destroyed.

In a software project, developers often do notice that the existing design and code is not clean, yet managers and leaders focus on ‘getting the work done as soon as possible’ rather than on ‘getting it right’. Given the fact that the programming best practices have already been abandoned, there is no reluctance in breaking more rules, particularly when no one notices. This quickly leads to chaos, and the software becomes fragile, leading to scrapping the project.

I don’t touch what isn’t mine

In the company, I’ve already mentioned, there was a bug captured from time to time thanks to some smart monitoring system. When I saw its history, it turned out that the bug appeared at least once in a week. My natural reaction was a question:

Why is it still there?

Developers had a full stack-trace, and it was only a matter of digging into a particular file to find out what’s going on. What I heard at that time from these programmers, must have made my face really weird looking

The bug comes from the part which was not implemented by us

It is very sad when you see people who basically don’t care. Or maybe they care, but only about their stuff. Other things are irrelevant and don’t matter. Think if you are not one of them.

If you work on something in particular, care also about the system in general. Not only about the part you are really responsible for because there isn’t anything like a selective responsibility. If you are a part of something, you represent this as a whole. There isn’t your code and their code.

Subscribe to get the latest content immediately

https://tinyletter.com/KamilLelonek

Summary

Ruby programming has a motto designed to promote positivity and goodwill among community members:

Matz is Nice And So We Are Nice

The widely publicized positivity of Ruby’s creator caused it to become a common maxim within the Ruby community.

I’d like to promote something similar regarding our code. In this article you learned:

To leave code better everytime you open it To fix things even you are not the one who broke them To care about what are you doing in a bigger context

I’d like you to follow these things. Think for a while, wouldn’t be awesome to see clean and readable code everywhere? If you think so, start from your own playground and be an example for others.

Resources