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.

!commentForm