Stop. Reflect. Adapt. The 3 Steps to Stop Writing Bad Code

Creative Commons License chad_k

Writing software that doesn’t suck is hard – even for the pros. The problem doesn’t lie in solving a hard problem, but in creating a solution which is easy to understand, robust, and easy to change.
A lot of problems in teams and organizations stem from bad code. Bad code ruins the motivation of your team, slows you down to a crawl and drags you down, deeper and deeper into the fire fighting vicious cycle.

Why do we write bad code?


Let’s try to understand a few reasons why we continue to write bad code, even though nobody wants to do it.

In my experience, a lot of developers always feel under pressure to deliver faster. Of course, there is constant pressure to finish a product faster. And of course, everybody should work towards the goal of getting features out to the customers asap. The issue is that too many software developers cut corners when trying to speed up. They don’t write automated tests, they don’t refactor their code after finishing an initial draft of working software, and they claim they’re done even though only the most basic flows are working (and they never took the time to thoroughly test border cases).
We all know where this leads to: Dropping half assed features into QA creates a myriad of bugs and a lot of hassle fixing the left overs of the rush. Not having any automated tests makes you play russian roulette every time you touch your code, and adding and patching a draft version of the code makes it worse with every bug fixed.
Everyone feels it: Your code is going down the drain.

How can we break that vicious cycle?

If you’re stuck with a shit load of crappy code you have to stop the downward spiral. The recipe is simple, but, while it will get you into the right direction, and it will lead you a path of evolutinary code and culture improvements, it’s not a quick fix nor a silver bullet. However, it’s your only chance. There are just three steps:

Stop. Reflect. Adjust.

Stop

First of all, you’ve got to realize you can’t go on like this. You’ve got to stop the line. This sounds very counter intuitive given the fact that you’re late already. But, only by stopping can start improving.

Reflect

Get everyone into one room. Ask them for noteworthy events within the last week. What did they experience? What got in their way? Make it clear this is not a blaming game, just a fact-finding mission. If you’ve collected enough, give everyone five points to distribute among the issues: Let them put as many of their five points on any issue they think should be addressed first. With this exercise, you get a shared understanding of the trouble spots and a first assessment of what’s worst. This is your input for the next step.

Adapt

Take the one issue which got the majority of the rating points in the reflection meeting. Make its resolution top priority for the coming week. This will signal to your team that you take their problems seriously, and you won’t continue repeating the same mistake. Address their concerns and show them how to get better – one step at a time.

Repeat

Repeat the reflect and adapt steps every week. Make sure, you address the worst issue every week. Interestingly enough, in the first weeks most issues won’t be considered to be in the area of the team’s influence. As the team lead, you have to make sure to get them resolved. Over time, however, the team will become more self confident and tackle more and more issues on their own. Now you’ve created an upward spiral where you get better and faster every week.

Have you ever experienced similar situations? How did you deal with them? Let us know in the comments below!

2 thoughts on “Stop. Reflect. Adapt. The 3 Steps to Stop Writing Bad Code

  1. Unfortunately, sometimes, these situations leads you to a dead end way. Sometimes you can not change the development style if a order don’t comes from upside.

    I fix the time problem with, sometimes, working for free, out of office. I think in my life’s quality forward, when the maintance time comes. I think, also, that I can convince other people to work with better methodologies if I prove doing.

    Great article. Congratulations! I think the same way.

    Regards

    Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.