“Hardest-first” vs. “Easiest-first” and TDD

7 11 2014

The interesting and thought-provoking “Is TDD Dead?” debates, and some explanations and examples of TDD that I’ve seen since then, have reminded me of something that came up whilst studying Computer Science at university (in the days long before TDD).

A few of my fellow students would develop programs by starting with the hardest parts of the problem, but the majority would always start with the easiest parts (obvious edge cases, validating input, “boilerplate” code etc).

In general:

  • The “hardest first” programmers wanted to crack the heart of the problem and eliminate risks and unknowns before bothering with the more straightforward work. They’d start out by just thinking, and wouldn’t worry about not yet writing any code. They were confident they could get the easier stuff done in due course, but didn’t see any point doing it unless and until they’d solved the main problem. They also didn’t want to be burdened or constrained by existing code when tackling the difficult bits.
  • The “easiest first” programmers wanted to start making progress and to immediately feel that they were getting somewhere and weren’t “stuck”. Having “momentum” and seeing progress helped them to continue. They’d generally start hacking something out without particularly worrying about it, and then fiddle with it until it seemed to work, whilst deferring anything that looked difficult until later. They felt the hard parts would be easier to tackle once everything else was already in place, even if some existing code would then need revising. At the very worst, if they did get stuck they’d at least have some code already written.

One of the lecturers noticed this, and the class ended up explicitly discussing it. When questioned, a few of us with previous programming experience generally favoured “hardest first”, but most of the rest thought “easiest first” was the best approach – and still thought that after discussing it. Notably, each group regarded the other approach as a horrible way of doing things.

At the time I assumed this was simply due to most of the students being new to programming, understandably struggling to get to grips with it all, and lacking experience with non-trivial problems.

However, much of the advocacy and explanation of test-first, test-driven development that I’ve seen has struck me as sounding remarkably like the sorts of things that the “easiest first” students might say. Listen, for example, to Kent Beck’s initial explanation of TDD’s origins and how it suited his personality at about 7:10-8:15 in the first “Is TDD Dead?” discussion.

Similarly, whilst I’m not particularly against TDD (and am happy to do it where it seems appropriate, or where it’s how a team is doing things), I do have some doubts and skepticism about test-first, test-driven TDD, and I now think this might reflect my own “hardest first” tendency. Even when doing TDD I often feel I’d have more quickly reached a better design if I’d tackled the “hard” problem of code and design directly instead of having to be led to the code piecemeal through tests and refactoring. Some of David Heinemeier Hansson‘s views in the “Is TDD Dead?” debates also sound rather like this to me.

So I’m starting to think that “test first” and “test driven” is perhaps most natural and beneficial for those who tend to be “easiest first” programmers, but can seem unnatural and unconvincing to those who tend to be “hardest first” programmers. In turn, the almost universal adoption of TDD that I see in local start-ups and job ads strikes me as implying that the “easiest first” viewpoint is now somewhat of an industry standard.

Perhaps most people are just intrinsically “easiest first” – at least to start with, and in the absence of any training to the contrary or when left to their own devices. Practices that work well for “easiest first” people are then perhaps a better industry-wide solution than anything that needs a “hardest first” mindset. I suspect this is now self-perpetuating, given the extent to which TDD is both advocated and demanded.

My only worry is that we’re perhaps denigrating and discouraging anyone that doesn’t fit that mould (especially if that might be me!).

I do hope we’ve not reached the point where it’s automatically seen as wrong to stop and think instead of diving straight into writing a test for some “simple” case.




One response

21 12 2015

Nice post, thanks. Quite usfeul. I heard about writing the tests first, but didn’t consider applying the same logic to legacy code. Unit testing does reduce the stress a lot, you can concentrate on one thing at a time, and feel less loss and entangled. MIT has great materials, I’ve found their Open Course Ware to be wonderful. Even the introductory programming course introduced the unit testing approach.I certainly hope you will keep up this blog!I myself am only an apprentice programmer, and that’s what I blog about. For now I’ve written about web and scripts, but will cover the fundamentals as well later on (algorithms etc.)Good blogging and programming!

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: