Writing Intentionally Bad Code
Out Of Date Warning
Languages change. Perspectives are different. Ideas move on. This article was published on March 6, 2013 which is more than two years ago. It may be out of date. You should verify that technical information in this article is still current before relying upon it for your own purposes.
I’ve done my fair share of speaking; I won’t say I’ve done a lot of speaking (not at least compared to people like Laura Thomson, Chris Hartjes or Rafael Dohms), but I’ve done a bit. Every time you speak people expect to see code in your slides. And they expect to see both a wrong way and a right way to do a particular thing.
That’s all fine and good; slides aren’t big enough to write an entire application. But in preparing for my class, The Object Oriented PHP Masterclass, my task has been to write a complete application that my students can refactor using the principles they have learned. And writing code wrongly, on purpose, is hard.
Breaking carefully cultivated habits
Part of the challenge in intentionally writing bad code is the need to fight against years of habit building for writing code the right way.
After all, writing code correctly is the skill I’m hoping to impart upon my students. It’s a skill I’ve carefully cultivated. Looking at bad code, I have an instant idea of what needs to change and why. I know, for example, that duplicated code should be refactored into a function. I know that an object that has HTML in it is doing it wrong. I know that an object with more than one job should really be broken into two. I know that private methods can be bad, especially in classes from which other classes must inherit.
Yet in order to teach these topics, I must do the wrong things, on purpose. For others to learn, they must encounter carefully constructed bad code.
Bad code isn’t enough
Note that I said “carefully constructed bad code.” Simply writing bad code for my students isn’t enough. I must write carefully constructed bad code. There’s a difference.
When inexperienced developers write bad code, their code is just bad. It has few (if any) redeeming qualities. It often must be scrapped, or at a minimum refactored intensely.
I’m not trying to have my students rewrite this code completely. I want them to be able to refactor it, to make it better, to look at carefully constructed problems and say “oh, that can be improved with abstraction!” or “oh, I can write an interface for this!” I want them to see solutions in the code, based on the material I’m preparing. I want them to be able to implement the answers based on their understanding of the course.
This is a very different type of “bad coding”. It requires deliberate action.
Of course, there’s tons of examples of bad code all over the internet. Why not just adopt one of those for my students to work on?
Because if you’re taking my class, which is two weeks long, you don’t have the time to understand something like WordPress, let alone refactor it. The size of the code base matters a great deal in developing and cultivating understanding.
The application I’m building is essentially a Hacker News clone, with ratings, comments, submissions, and authentication. This is just large enough to provide a number of avenues for demonstrating mastery of the material, but small enough that it can be refactored in a couple of weeks.
Challenges abound – but it’s worth it
One of the best benefits of being a teacher is that I have the ability to see how what I do affects the student. And even though teaching is a challenging task, it’s one that’s well worth it!