Link to Post

[Reading time: 52 seconds] I was surprised to see that so many of my subscribers responded to yesterday’s email about null automation. I think this warrants a second look. It seems that what people liked about this tip was how it married several aspect in a very usable, approachable way: it’s about technology and its concrete application at the same time it takes into account the human/process aspect of uncertainty it allows for flexible, efficient reaction to the situation it enables communication (because now the process is written down) But what stuck out most was that this was an efficient and pragmatic way to address uncertainty. Read More →

Link to Post

[Reading time: 1 minute 16 seconds] I love the idea of null automation. It’s one of these small but neat tricks. Sometimes you’d like to automate something, but you don’t want to go all in: maybe you don’t have the time yet, or you’re unsure of the effort, or the process is just not mature enough yet to commit to the effort and rigidity of creating automation. So, what now? Read More →

Link to Post

[Reading Time: 1 minutes 19 seconds] One of the great things about writing code is that it allows you to preserve information that might otherwise be lost. Especially if you’re building infrastructure, which traditionally meant writing readmes or other kinds of documentation that gave an inkling of what needs to be done. But of course there are lies, damn lies, and documentation: you can be sure your documents will be out of date, and incomplete (turns out it’s really hard not to miss a step, particularly the ones that seem obvious to you). Read More →

Link to Post

[Reading time: 2 minutes 11 seconds] One of my aerospace engineering professors said that “engineering is the art of cheating, and getting away with it”. He’s… not wrong. It’s still dangerous advice though. Because barely getting away with things goes well, until it doesn’t. And then your shiny new 737MAXes fall out of the sky. The 737MAX is such a fascinating example of how choices in engineering often don’t lead to disasters in blatant, obvious ways, despite the disasters themselves being very, well, blatant and obvious. Read More →

Link to Post

[Reading time: 1 minute 5 seconds] Many organisations, even the most stuck-up ones (or perhaps especially those?) sometimes work in an Agile fashion. It has been my observation, however, that they tend to do it by accident, not realising what happens. Maybe you’ve observed this too: when a project is in sufficient distress, management decides on energic measures: they found a task force. Experts from various disciplines get pulled into this task force, told to drop their other responsibilities, make swift decisions, and focus on working together with their colleagues to, as the German saying goes, get the cow off the ice. Read More →

Link to Post

[Reading time: 2 minutes 15 seconds] I frequently hear the claim that Agile only works for software. In fact, many software engineers claim Agile can’t work for them (for whatever reason). Baloney. (You may quote me on that) For example: I consider the Apollo space program an Agile program. No, of course they weren’t following the Scrum guide. And of course they didn’t run two-week iterations. But they did absolutely follow the spirit of Agile development: focus on discovery, and keeping yourself as open as you can to make use of what you discovered. Read More →

Link to Post

[Reading time: 35 seconds] Have you ever watched a millipede go about its business? They’re interesting creatures. If you have, maybe you’ve observed one navigate a crack in the floor, or other such gap. It’s interesting: the first few legs will step into air, but all the many others won’t: they won’t even try to walk there. Save for the first one, two pairs, they’ll just keep their legs raised until they know each individual pair to be on terra firma again. Read More →

Link to Post

[Reading time: 1 minute 24 seconds] Yesterday I talked to you about doing things right. Today, I want to talk about being wrong. But not just any old wrong, but the right kind of wrong. Engineering is full of surprises: technical, or human, or business. And surprises in engineering have this annoying tendency to be the bad kind. So inevitably things won’t go the way you want them to. Or perhaps you learn of a better way to do something. Read More →

Let's Get In Touch!


Do you have a question? A project proposal? Something special in mind? Contact me, and let’s talk about how I can make your team, your products, and your life better