I always considered a checklist, a checklist, so I was interested to learn the distinction between two types of checklists: Read-Do and Do-Confirm.

A Read-Do checklist might be prepared in advance for several potential possibilities. You check off the tasks as you do them, like following a new cooking recipe. They may be geared towards helping people understand what they should be doing and in what order and helping them remember key steps in unusual or unplanned scenarios. So, for example, if a plane develops a particular type of rare fault, such as an engine failure, a Read-Do checklist could be pulled out for that scenario. The pilot and crew can use it to make the most of others' past experiences and failures. Even with training, given the situation's relative rarity, and especially if a serious situation might interfere with normal thinking, a Read-Do checklist helps steer the crew to safe outcomes without relying solely on training and memory. The calm security and simplicity of steps of a checklist can be just what's needed.

A Do-Confirm checklist is more of an aid to memory to make sure nothing gets missed. It's a safety net for normal operation catching lapses in memory. In principle, we know what to do, so we run through those steps from experience and memory and use the Do-Confirm checklist at a designated pause point to ensure we didn't miss anything. The WHO Safe Surgery checklist has helped save 1,000s of lives.

Because a simple checklist can never account for every unexpected occurrence in complex environments—for example, healthcare, aviation, building a skyscraper, or software projects—both checklist types can benefit from items that require a communication step. An item can just be to ensure that all those with the relevant knowledge have discussed things. It's a simple and powerful way to improve outcomes across a wide range of unexpected scenarios.

I learned about the simple power of checklists, the two types, and the resistance to adopting them—from Atul Gawande's, The Checklist Manifesto: How to get Things Right.

Two types of checklists: Read-Do, Do-Confirm

Cake Wrecks is the blog and book of when professional cakes go hilariously wrong, by Jen Yates. But a cake wreck is also a useful metaphor for how easy it can be to misinterpret instructions—often by simply taking something literally when it was expected to be interpreted. Examples from Jen's collection include a smart-looking cake with "Nothing" written across the front, a graduation cake with "I want sprinkles" next to a graduation cap, or a cake sporting a full "Happy birthday on a gluten-free cake." If you haven't seen them, you could do much worse than look some up now. It's easy to laugh at these examples, but it's also easy to find real examples in day-to-day work.

I learned about cake wrecks from Jeff Patton's excellent book User Story Mapping. He gives cake wrecks as an all too common example of communication in software development. For example, a user story or specification for a feature is written and passed on to developers who, in the absence of other communication and with perhaps cultural or status barriers, may carefully build exactly what is written rather than what the writer intended. Cake wrecks are funny and silly—except if it was for your special occasion—but mistakes in projects are expensive in time, money and relationships and are worth avoiding.

The recipe for avoiding a cake wreck is, in principle, simple:

Don't assume that what you see is what someone else will see

Use stories and specifications as tools for talking about what's needed and not as equivalents of it

Create a safe space for everyone to question what they don't understand or don't agree with

Give everyone the 'why' behind a project and autonomy and flexibility to suggest other ways to meet the goal

Check in during a project and adjust as needed

Cake wreck

The bus factor is how exposed you are if key people, perhaps with critical knowledge or skills, were hit by a bus.

Examples might include the only people able to keep a company running, restore a server from a backup, or someone who held the only key to unlock crypto assets of its customers. As a result, many places are set up with, or required to have by investors or insurers, some redundancy — say two experienced developers with knowledge of how a service works — to minimise the risk of a tragic accident also being a severe problem for a company or its customers.

As a metaphor, the bus factor may be helpful to consider without the need for people to actually be hit by a bus. It may be worth thinking through how you might operate if someone was late, missed their flight, was ill on the day, or simply quit. In operational roles, this will often lead to a minimum of two people for each key position if nothing else to allow one to take a break from time to time.

An alternative framing, with fewer fatalities, is 'what if we all won the lottery?' and so decided to go do something else.

Bus factor

Anyone who's tried their hand at research, built some software, or even run a kid's birthday party may relate to this idea: In theory, practice is the same as theory, but not in practice.

It's a lovely encapsulation of similar ideas to "All models are wrong, but some are useful" or "No plan survives contact with the enemy." Or one of my favourites, Hofstadter's Law: "It always takes longer than you expect, even when you account for Hofstadter's Law."

The quote, in varying forms, has been attributed to a number of people — QI suggests that Benjamin Brewster should get the credit from 1882.

In theory, practice is the same as theory, but not in practice

Just as mistakes and the unexpected are part of life, bugs are part of software development. In general, the longer the time between when a bug was first introduced and when the bug is identified and fixed the more expensive it is in both time and money.

If you spot a bug as you're writing a new feature everything is fresh in your mind and it can sometimes take just a moment to fix.

If a bug turns up later or perhaps soon after it's deployed you might have an idea of where it might be and track it down fairly quickly.

If a lot of time has passed since a feature was worked on and a bug is spotted or tackled then it might take a fair bit of time to figure out how everything works again before you can fix it.

And if a really long time has passed then, aside from the cost of interrupting what you are otherwise working on, it may not even be clear what was intended by the original code, probably written by others, and there's a fair chance more has been built on top of the buggy code making it more complex and a bigger task to tackle. The only way to solve it may be stepping through and figuring out behaviour slowly and steadily line-by-line.

You could probably replace 'bugs' with 'code' 'problems' or 'mistakes' in most scenarios.

Aside from it matching my experience, Joel Spolsky gives a nice explanation in his classic article The Joel Test.

The cost of fixing bugs

The chaos monkey is a smart piece of software and a brilliant idea from engineers at Netflix.

The chaos monkey deliberately switches off servers in live environments at random. It takes the pain of disappearing servers and brings that pain forward. By deliberately sabotaging their own systems it created strong alignment for the team to design-in redundancy and automation for the necessary resiliency and reliability in the face of random failures. Training for this randomness helps make stronger, more resilient and fault-tolerant systems and software and keeps your movie streaming so you can keep chilling without interruptions.

The chaos monkey is a great metaphor and trigger to actively work on what life could throw at your system before it happens.

More monkey inspiration for writing and for bananas.

Chaos monkey

When adding features to a software product it's easy to underestimate the overall time and cost they may take up. To keep the full impact in mind it can be helpful to think of Features As Pets.

When I think of Features As Pets it helps me look past the initial cost of designing and developing a feature and consider its full lifecycle. For example:

you're going to want to tell your users about it

you'll want to check it's being used as intended

you'll need to support it and check that it works in all different places and fix it when it breaks

you may need to work hard to make sure it's compatible with new features you add

you may have to return to the code and refactor it to improve performance

you may need to upgrade libraries and maintain security patches

finally you'll have to decommission it gracefully when it's no longer needed including dealing with data you may have stored

New features are probably one of the key differentiators of your offering compared to others, but it bears a little consideration before adding something — a feature is not just for Christmas.

Features Are Like Pets is from the excellent Intercom on Product Management podcast (Apple, Spotify, ebook).

Features are like pets

Conway was mostly observing software development, but I would think it has some application to any large project: cruise ship design, car design, space shuttle design, heck maybe even governments and law.

Law is kind of a strong word for an observation, but in any case, here are some other ‘laws’: Fitt’s law, Metcalfe’s law, Goodhart’s Law, Muphry’s law, Moore’s law, Koomey’s law, the law of diminishing brownies, the law of lockers and, my favourite, Hofstadter’s Law.

PS: As you read this I may be cycling mid-lake and trying not to sink to raise money for charity: www.cycleorsink.com

Conway’s Law

This is surely at least part of the reason that “software is eating the world.”

But I’m sure coffee will stick around for a bit too.

Rival and non-rival goods

Did you you know, a rubber duck can help you solve your problem? Or, a teddy bear, or, heck, a table, whatever. Have you ever been called over to someone’s desk to help them solve a problem, and as they explain what they were doing to you they figure out the answer themselves?

Rubberducking is the simple technique of explaining your code, or whatever you’re working on, to a rubber duck, and, in the process of explaining it, finding the answer yourself. Rubberduck debugging is a term in software development as the process of figuring out a solution to a bug or problem. Surprisingly effective, and way cheaper than hiring a contractor for the day.

Rubberducking

Smaller software releases generally means fewer bugs, and bugs that are easier to fix. The number of bugs created typically increases with the complexity of interactions of code, which in turn increases with the size of release. This means that a number of smaller releases can hopefully get you to a large change in a safer way with less bugs, and less problematic bugs, created along the way than a single release with the whole lot. There’s probably a somewhat more general relationship with amount of unexpected problems created and the size of any change.

Bugs and releases

I love this diagram by Henrik Kniberg for how to think about what to release to your customers when. Hopefully it’s self-explanatory, but the idea is that a standard approach of having your grand plan of what you think people want at the start and then working on each bit at a time until finally, after months of work, you have something that works is not, when explained like that, so smart. Each piece, in the car example, doesn’t help the customer at all until it’s all put together.

Instead, you can focus on providing the next piece of functionality that helps someone get their job done a little better than before. At the beginning they’ll probably have to put up with a lot if they want to use it, but with each successive release they find they can get their job done a little better than before and get value out of what you’re building. A side-effect is the feedback you get along the way will likely help you learn and build something that is better than what you had in mind at the beginning and all along the way the customer had some value instead of waiting for months.

Providing usable functionality at every step is not always easy, and it usually involves some rework as you move from one step to the other. But it’s generally a price worth paying to give your customers value sooner and start learning as soon as you can.

HT: the brilliant User Story Mapping by Jeff Patton and Kevin Alves

A release strategy for happier customers, sooner

Idempotence is essentially an operation that, no matter how many times you do it, you’ll still get the same result, at least without doing other operations in between. A classic example would be view_your_bank_balance being idempotent, and withdraw_1000 not being idempotent. It’s a property that’s often handy as you can retry the operation without worrying about unintended effects.

Idempotence is a concept from mathematics and computer science but can be applied more generally. For example, simple on and off buttons are idempotent, a property that can be very useful in emergencies.

Idempotence

A way of helping decide what to do next based on Must do, Should do, Could do and Would do.

Strangely, so many of the things you’d really like to do when put in this organisation end up in the Would bucket.

MOSCOW Prioritisation.

Desire paths: created by desire and use. Sometimes I find myself walking on the traces of one as a statement that ‘there ought to be a path here’ - voting with my feet.

There’s the classic, perhaps apocryphal, story of the architect who didn’t build any paths on a campus until people had worn them in, showing where the paths should be.

The phenomena has found use in technology with the phrase 'pave the cowpaths’.

One emergent behaviour-related concept arising from architecture and planning which has also found application in human-computer interaction is the idea of desire lines, desire paths or cowpaths. The usual current use of the term (often attributed, although apparently in error, to Bachelard’s The Poetics of Space (1964)) is to describe paths worn by pedestrians across spaces such as parks, between buildings or to avoid obstacles—“the foot-worn paths that sometimes appear in a landscape over time” (Mathes, 2004) and which become self-reinforcing as subsequent generations of pedestrians follow what becomes an obvious path. Throgmorton & Eckstein (2000) also discuss Chicago transportation engineers’ use of ‘desire lines’ to describe maps of straight-line origin-to-destination journeys across the city, in the process revealing assumptions about the public’s ‘desire’ to undertake these journeys. In either sense, desire lines (along with use-marks (Burns, 2007)) could perhaps, using economic terminology, be seen as a form of revealed user preference (Beshears et al, 2008) or at least revealed choice, with a substantial normative quality.

Architecture, urbanism, design and behaviour: a brief review, Dan Lockton, Sep 2011

Or see this very concrete example from UC Berkeley at peterme.com.

Desire path

I learned about this nice principle from agile software development. Basically, that when thinking about how much you’ll get done next week, what you got done this week is a good proxy. Sure this week was different because you had that external presentation and an offsite, a bug to fix on live and Amy was sick. But the reality is things will interrupt you next week too. Just like the weather, what happened before is a good first guess at what will happen next.

Yesterday’s weather

Hofstadter's Law is one of my favourites.

“It always takes longer than you expect, even when you account for Hofstadter’s Law.”

Sketchplanations tagged with software