Ron Jeffries published a wonderful post titled “working software“. He quotes the agile manifesto “working software is the primary measure of progress”.

Now, he explains that what exactly “working software” means depends (as always). But in general,

Working software is real. It works. It can be tested. It can be verified. Questions about whether it does X are readily answered with “Yes” or “No”. The less ambiguity there is in our answers—our true answers—the closer to “working software” we are.

And he shares his opinion on “best development style”:

The best development style we know today, whether working solo, in pairs, or in a mob, is to pick a very small thing that the system doesn’t as yet do, verify that it doesn’t do it, then make it do that thing, verifying again, and keeping the code at or above our standard of internal quality.

How small should that thing be? Tiny. Smaller than that. No, smaller still.

I repeat that:

  1. pick a very small thing that the system doesn’t do yet
  2. verify it doesn’t do it (the “red” step in the TDD cycle)
  3. make it do that thing
  4. verify it does it (the “green” step in TDD)
  5. keeping the code at or above our quality standard (the “refactor” step in TDD).

I really like that. It’s not always that easy. But more often than not.

I know of TDD but I need to get better at remembering this (I’ll put that in my Anki deck) – including the very small part – and then practice it.

In Who do you want to KISS? – About simplicity in coding Ralf Westphal reflects on what simplicity means in programming.

He observes that simplicity is relative, esp. relative to the “scarcest resource”. For Ralf “in the long run the scarcest resource therefore is reading or modification time“. In TDD there is a step when you can create simplicity in respect to reading/modification time:

It means, you need to find time to optimize for reading/modification later. Interestingly TDD has this time built in. That’s what the refactoring phase is for. During refactoring you apply the KISS principle once more – now creating simplicity for reading/modification time. If thereby the simplicity for coding time is destroyed so be it.

And even then, simplicity regarding code reading and modification is in the eye of the beholder. Some programmers like high level abstractions like higher order functions while other like a more verbose but easier to follow procedural style. This is often related to the level of experience:

A simple solution for one person can be a complicated solution for another person. Sad, but true. The only way out of this is to keep all team members close together in their competencies (as long as there is a chance one member needs to deal with another’s simple solutions).

(This is a repost from my other blog)