March 22, 2021

Over the past few years, as is normal, I’ve changed my mind about a few things.

Some of these were previously fairly strongly held opinions, so I thought I’d summarise six of the most significant in a blog post :)

  1. Estimation is a good use of your teams’ time.
  2. I need a high-performance laptop for programming.
  3. Lacking external validation, climate models are unready for use by policymakers.
  4. Test Driven Development is the best way of building software.
  5. The new Land Rover Defender is a pale imitation of the old Defender and Series.
  6. The ThinkPad X series is the best small laptop series on the market.

Estimation is a good use of your teams’ time

For years I’ve advocated that teams practise some variant of Planning Poker in order to estimate the relative amount of effort involved in building new software.

My experience has been that such estimates:

  1. Work. Given conscientious application on the part of dev teams, you’ll get meaningful story-point estimations of each story.
  2. Map to calendar dates. Burndown charts will give you a good sense of your velocity, and likely ship dates.
  3. Require a lot of effort. Taking estimation seriously, and doing it well, takes a decidedly non-trivial amount of the team’s time, especially in an area with lots of discovery or changing requirements.
  4. Assist understanding. In order to meaningfully estimate things, teams will need to at least superficially understand what it is they’re planning to build. A serious game of Planning Poker will flush out any lack of understanding.

So, estimation works, but it’s an expensive and highly-skilled activity. Based on some conversations with my friend Nigel Thorne, and a few years experimenting while managing multiple dev teams, I’ve reached the conclusion that there’s a better way:

  1. Know your mean story cycle time, in calendar days. That is, the mean time it takes from a story to get picked up, to it running in production. That definition is crucial; you need to include time spent waiting for QA, deployment, feature-flag ramp up … everything.
  2. Know the standard definition of cycle time. This figure may surprise you; it regularly surprised me. In fact I’ve seen more than a few teams whose stories and/or deployment processes were so variable that the standard deviation exceeded the mean.
  3. Break down your project into (hopefully) similar-sized stories (grouped by epic if needs be).

JIRA will give you mean cycle time, and standard deviation of cycle time, in the Control Chart report.

At this point, your project end end date is easily calculated: the number of stories, multiplied by the mean cycle time, divided by the number of developer pairs you’ll have working on the project.

You can then plot the date and error bars on a JIRA Cumulative Flow report, modified to remove ‘done’ stories, and filtered to the epic in question.

But perhaps the more interesting detail here is the error bars. I assume error bars of +/- one standard deviation for each story. This adds up pretty quickly; it’s not uncommon in my experience for those error bars to be really wide once calculated and plotted.

A simple example from a single epic from a past project:

Epic Projection

The first thing to note is that this is super lo-fi. We’re talking lines drawn on a chart with a pen and a steel ruler. Looks as vague as it really is.

Next, the error bars are ridiculously wide, to the extent that the earliest ‘possible’ ship date is in the past! The team in question spent some of their time working in a system with a fortnight-long release process involving a bunch of manual QA. Cycle time legitimately was really variable, and that was reflected in the great uncertainty of the projection.

With the above approach you still get the benefit of understanding (having to do the epic and story breakdown), and a calendar date projection of completion. However the level of uncertainty is much better understood, and it rewards better process (more predictable deployment, finer and more consistent story breakdown, etc.) with better projections and narrower error bars.

The main selling point though is that they get those benefits with (in my experience) far less effort required. Just ~ 10 minutes per week of a manager’s time (to keep the projection current!), a printer, a ruler, a spreadsheet, and a pen :)

I need a high-performance laptop for programming

With work mostly remote these days, and NBN (broadband) Internet at home running 90Mbit/s down / 25Mbit/s up (good by Belgrave standards!) I’m changing my plans around development machines.

In the past I’d buy refurbished ex-corporate ThinkPads, optimising for price-performance. Instead, I’m planning for my next development machine to be a refurbished ex-corporate server (maybe a ProLiant?) installed in my server cabinet (topic for another future blog post!), using a laptop merely as a thin client over my personal VPN.

I’m seriously considering purchasing a PineBook Pro for that purpose, and leaving my W540 as a gaming machine - the only case where I’d still need x86_64 and a high performance GPU.

Lacking external validation, climate models are unready for use by policymakers

Up until recently, I’ve been highly skeptical of climate models, as they’ve lacked any sort of external validation. In the past few years, though, satellite measurements of sea surface height has confirmed thermal expansion in a manner completely separate to the measures and models used for predictions.

My opinion is now that we should choose, as a species, to formulate a rational response to AGW based on cost-benefit calculations derived from the results of these models.

(Of course, we won’t. Anti-capitalist radicals will continue preaching the entirely unfounded scenarios of human extinction or billions of deaths, and shills and the politically-committed on the other ‘side’ will continue pretending that AGW isn’t happening at all. Not to mention that this is the mother of all prisoners’ dilemmas; even if say Australia went entirely carbon neutral tomorrow that’s around 1% of global emissions. So I’m not confident that anything like a correct approach will happen here.)

Test Driven Development is the best way of building software

For years I’ve advocated TDD as the best way of ensuring that the code you’re writing is fit for purpose: well designed, well structured, and (last and least) well tested.

Based on my recent commercial experience with Common Lisp, however (a subject for a subsequent blog post!) I’ve come to the conclusion that TDD is what you do when you don’t have a sufficiently powerful interactive development environment like SLIME:

My traditional TDD workflow goes:

  1. Red: write a failing test.
  2. Green: make the test pass.
  3. Refactor: with the previous and earlier tests as a safety net, restructure the code to be optimally readable and maintainable.
  4. Repeat.

Whereas in a REPL-based environment like SLIME, I find myself doing:

  1. Wishful thinking: invoke the code as though it existed.
  2. Hack: implement a naive version of the code that gets somewhere towards a full implementation, testing it interactively through the REPL.
  3. Test: add tests to formalise the invocations performed during Hack.
  4. Refactor: with the previous and earlier tests as a safety net, restructure the code to be optimally readable and maintainable.
  5. Repeat.

It’s a subtle distinction, but leads to much faster feedback loops early on, but still winds up with a test suite and well-factored code. Note that at every point past (1) above, you have working software that’s running in your current Lisp instance, so feedback is immediate.

My new opinion here is: TDD is what you do when you don’t have a sufficiently powerful REPL.

The new Land Rover Defender is a pale imitation of the old Defender and Series

For years I’ve been a fan of Series Land Rover and Defender models - especially our old Series 2 FFT, Rosemary.

I was highly skeptical of the new Defender series, believing that Land Rover had nerfed it by abandoning the old Defender platform. It turns out I was wrong: the new Defender looks more capable than the old one, while demanding far less of the driver.

My new opinion here is that computer-controlled off-road vehicles are now superior in most cases to human-controlled off-road vehicles, and will continue to improve over the coming years.

I’m still a great fan of the older Series and Defenders - they’re lovely classic cars. But they’ve been functionally eclipsed by the latest generation.

The ThinkPad X family is the best small laptop series on the market

This used to be true; it’s not so much that I’ve changed my opinion, but that Lenovo has nerfed the X series. I recently swapped the hard drive on an X200 by removing a single Phillips head screw and sliding out a caddy. Swapping out the drive in an X230 involved removing the entire (flimsy!) back cover, and swapping out the keyboard was a very involved process that dealt with a bunch of my least favourite things: tiny, fragile, ribbon connectors that were unrelated to the keyboard-swapping problem at hand.

I no longer recommend the X series on the basis of user serviceability, which is a problem given I run a fleet of them for our children. I’d seriously entertain switching to the PineBook Pro, except that the sprogs require an Intel processor for gaming (VirtualBox, Starbound).

I don’t have a better recommendation yet, though. I plan to keep looking.