ArticleS. TimOttinger.
TheCheesiestThing [add child]

The Cheesiest Thing that Might Work

Back in the day we talked about doing the Simplest Thing that Might Work. And we meant it. Simplicity is all about minimalism, about elegance free of opulence. It's the software expression of Occam's Razor. It's simplicity that makes a design clear, crisp, extensible, manageable. Being simple is generally very hard, and there are a number of design principles that help to express (in an elegant, minimalistic way) the forces and choices that lead to simplicity in design. You might have seen those around here.

But in TDD we do the easiest thing to pass a test. Easiest, not simplest. The easiest thing may involve duplicating some code, copying from elsewhere (keyboard inheritance). It may involve returning the expected answer instead of calculating it.

You might disagree, but I went through a number of coworkers, ex-coworkers, experts, and mentors and I found that the answer was always the same, to “do the easiest thing that works – write the least, think the least about it”.

Look at the first answer to the “gutter game” test in the famous bowling TDD example. When asked to calculate the score, we simply return zero. Really. Just return zero. No over-thinking it, no real study of the problem, just pass the test. Just get that green bar. This “{return 0;}” is a brute-force, least-mentality, quick-hit, future-vulnerable, ugly bit of code. Only its mother could love it. It's not something you put up on your refrigerator. It's unimpressive to say the least.

If there should be more going on, then our tests should express more, expect more. Our goal is to get tests passing, because refactoring is safer and more certain if we have test coverage (and somewhat insane if we do not). Refactoring will get the design right, if we can first get the right answers.

So my friend, aware that TDD wants us to turn off certain parts of our brain early on, coined the phrase “the cheesiest thing that might work.” I like it. It tells us that we're not to make ourselves proud of it, we're to make our test pass. Proud comes later. We're not looking for simplicity, just a green bar. No elegance, just crawl before you walk, just an answer so that our test is really in place. Turn off some of that cerebral mechanism and bring on the cheese.

Now the first time he said it, there were chuckles. Later on there was quiet. Last time there was some rebuke. One fellow felt that it showed a lack of respect for the process, but I don't think so. Really it's an extraordinary trust in the process to do this in expectation that TDD will take our lead and return gold to us – that it doesn't want us to think too much, too soon, because it might be able to show us a more excellent way. Also, it is a reminder that the first stumbling steps are not the way that the code should ultimately look. Passing the tests is just the first step, and our goals are higher than that.

In a field where it's easy to be overwhelmed it is probably important to realize that the first requirement of software is that it works at all. We need to get some paint on that canvass. That is a kind of goodness in and of itself. Once that is settled (and the tests confirm it) then all the other kinds of good can be considered. We should make it run, then make it right. Fulfilling the spec is just the first step in the process, right?

Feel free to disagree.

 Wed, 12 Apr 2006 09:20:12, David Chelimsky, this is your brain on cheese
I'm feeling free. And I agree with almost everything you say here. The metaphor of getting some paint on the canvas is beautiful. And watching you gain respect for the TDD process is awesome. But there are two things I must disagree with:

One is the word "cheesy". I'm the one who suggested there was a lack of respect, and I stand by that. For me, "cheesy" evokes bad taste, simple-mindedness rather than simplicity. Think vogon poetry. Think WNUA.

The other thing, far more important, is the notion of turning off your brain. That is NOT the goal of TDD in my view. The goal is to move your thoughts about specification out of the implementation and into the tests. When you return 0 to pass the gutter game test, it's a game you play against your "better judgement". You say "HA, I can pass this test in one keystroke". And your better judgement says "OK, fine. Here's another test - now make THAT ONE pass". It's not cheesy at all.

In the end, however, debate over the word "cheesy" is inconsequential. The bottom line for me is it's just ()*&)(ing annoying hearing it over and over and over again. It's like finger nails on a chalk board. Please stop it.

What's important is the way we think about what we're doing when we do the simplest thing to get the test to pass. And that our brain stays engaged through the process. All of our brain - not just the "inner designer" and the "better judgement".
 Wed, 12 Apr 2006 10:28:12, Tom Rossen, Repentant
I'm the miscreant in this story. I'm not using the c-word anymore. I like both Tim's post and David's comment. David brings up the game aspect, which is really what I was had in mind introducing the c-word in the first place: the idea that the TDD test-code (and don't forget refactoring!) cycle is a game. The game is not zero-sum - it moves the development forward. And it's fun, which is an underrated motivator for programmers (outside of the Agile universe), whether you're ping-ponging with a pair or working alone.

It was the fun aspect that hooked me when I first read Kent Beck's "Extreme Programming Explained". Kent's take on the psychological/spiritual aspects of programming was a major improvement on Weinberg's "egoless programming", which didn't seem to offer an upside for giving up private property in code.

 Sat, 15 Apr 2006 01:12:08, Matisse Enzer, Having fun is a good thing.
Coming up with cute, funny, or simply fun names for things is a Good Thing. Anything that increases Programmer Enjoyment might contribute to Program Quality, so, bring on the cheese :-)

The general idea of doing the least-costly thing to get to the next step has a long an effective history. With increased experience and skill we make better judgements abouty what :least costly" or "cheesiest" really means - how far ahead should we look? How about just painting the bar green on the screen? That'll get you 100% green bars, but maybe that's too cheesy :-)

By the way - the "paint on canvas: metaphor reminds me of a general assertion I've been trying to articulate about how the process of Software Development is more alike than different from the general process of Making Things, physical things. I blogged one rough version of that assertion at