“Who has written this crappy code?” – I did!


Today I thumbed over an amusing comic while catching up on blog posts:

I actually found it very funny, but it prompted a long discussion with a friend on IRC and I felt like sharing this.

Who has written this crappy code?

Let’s be honest, we’ve all asked it. We’ve all wondered. We’ve all used svn blame (or the equivalent).

We work in an industry full of very passionate people. We are very passionate people. We’re passionate about the great software we write. We’re passionate about wanting to improve ourselves. When we see bad code, we’re passionate to the point of frustration. Sometimes we’re passionately fearful that it was us.

I learned a very interesting answer to this question from one of my peers though, and that’s what I’m sharing today.

Who has written this crappy code?

I did.

For me it signifies a few things.

First of all, we all write bad code sometimes. It’s not something to be embarrassed about. How could anyone ever improve if they were unable to admit they have flaws that need improving?

Second of all, does it matter? Would knowing the answer actually help you fix the code any faster? Just pretend I did it, swear under your breath, then move on and fix it. Come tomorrow, you won’t respect me any less or more for it, so let’s not waste time with SVN blame, I’ll just take the blame up-front.

Lastly, the team owns the code. All of the code. (Sometimes I use the answer “we did”.) Even if the code was written before the current team, the answer “I did” or “We did” really signifies the idea that as a team we are responsible for the code under our watch.

Of all the ideas I’ve been introduced to in the last two years, this is one of the simplest and most powerful. Give it a try on your team, see how people react. You may be pleasantly surprised.



2 comments on ““Who has written this crappy code?” – I did!

  1. I suppose thorough code reviews before committing the source to the Head may help the team say we may write crappy code in the test release but we don’t allow it to reach the production release.

    • My team’s approach is mandatory pair programming. If it’s not paired, it’s not committed. We also don’t differentiate “releases” – anything that passes our automated build suite is considered a release candidate, and our customer proxy is free promote it to production.

      Unfortunately, we can’t prevent code written in the past. We only started our agile practices nearly a year ago, but I’ve been on the team for two years. Before we started working with agile, we had a lot of practices that allowed questionable code to hit repository. On top of that, it’s a 10 year old code base, and we’ve only recently committed ourselves to refactoring and improving it.

      Also, as we get better with various technologies, we often find our own recent code inefficient. For example, most of my team was relatively unfamiliar with mocking when we started using it. We started using mocks in our tests, but got carried away, and now we often look back and ask why on earth anyone would mock to the extent we did.

      I think my one teammate put it best: The second you commit, that code is legacy and starts accruing technical debt. You not only have to commit to writing good code, but commit to revisiting it regularly to keep it fresh and live.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s