Thought for Friday: What are we going to do about the crap code ?

Yesterday, my manager asked me “What are we going to do about the crap code?”

It’s a hard question to answer because before we can answer what to do about it; we must understand what crap code is and what causes it.

What is crap code? This is still a hard question, but I think we can at least attempt to answer it by defining what it isn’t:

  • Crap code isn’t maintainable
  • Crap code isn’t easily testable
  • Crap code isn’t as efficient as it could be
  • Crap code isn’t understandable without lots of comments

What causes crap code? In my experience it is some combination of:

  • Ignorance
  • Fear
  • Lack of experience, pride, oversight, accountability, time and analysis/understanding of the domain
  • Resume-building perhaps?

So what is the solution? There is no silver bullet, it requires vigilance and potentially each of these causes needs to be tackled individually.

Ignorance: One way of tackling this is encouraging learning, peer review and discussion in the organization. Time needs to be allocated to ensure that project work doesn’t stop these activities from flourishing.

Fear: One of the major differences between a good developer and an average one is the fear factor; good developers don’t have the same fear of changing something, or fixing something since they are confident they are not going to break something without knowing about it. Because of this, fear has the effect of destroying reuse – copy and paste code thrives in this environment. Besides learning how to study code, unit testing and other forms of automated testing are good for addressing this.

Experience: You need to install a mentoring system to ensure that the less experienced team members have someone to go to for advice. Team members need to be exposed to different types of development work. E.g. database, business-logic, front-end / web etc. They’ll never get enough experience doing the same thing day in, day out. Ensure every commit to the code base is emailed to the rest of the team, experienced developers should be reviewing the code and suggesting changes if required.

Pride: This is a hard one, and probably comes from the side effects of the other causes. One way is to allow team members to look after a particular module, service / sub-system.

Oversight / Accountability: Oversight is simple – review code and don’t compromise on quality – you’ll end up regretting it at some point. Generally speaking accountability decreases the more segregated the teams are.  I.e. if you have a team of testers that are separate to your developers, the less responsibility the developers will feel to getting something right – you’ll get a “throw it over the fence” mentality. Create a team with all disciplines (developers, testers, dbas, infrastructure etc.,,).

Time: This is about planning properly and ensuring that developers are aware of all the steps to produce bit of functionality. It’s also about being realistic when it comes to providing your estimates. Make sure you include time for producing your unit and integration tests, and don’t underestimate just so you get the job. Stress to developers that the job isn’t done until it is tested and works.

Resume-building: This is subjective but I’ve been on projects where the tech lead has read that this new piece of technology is the ducks and they wants to get in on it just so they can put it down on their resume. They manage to get all the newest and greatest stuff in there but at what price? The code under the covers becomes a maintenance nightmare because it is far to complicated for what it needs to do. Ensure that the technology you use is decided up front. Don’t deviate unless you get further sign-off from the stakeholders. Create a list of “guiding principles” (N.B. not coding standards) to decide how you’re going to go about writing the code – and enforce code reviews on these.

Understanding the domain:  When you start a new project it is really important, that at every step in the process you constantly to try to refactor based on your current understanding of the code. Data models are really hard to change once a system goes into production, so you’ve got to make an effort to get it right. If some aspect of the design doesn’t feel right, then it probably isn’t it. Don’t be in denial – fix it.  I’ve seen so much bad code and bugs caused because the new requirements or understanding about a system are applied to a broken domain.

The bottom line is, does crap code really matter? Who cares if it works, right? I think it does. And crap code is directly proportional to defects in my experience.  Defects will cost you money fixing them and cleaning up the consequences of them.

Fixing the crap code is no doubt a hard problem. The solutions involve constant vigilance and culture change – but it is worth it in the end.