Skip to content

{ Author Archives }

Head Labrarian at The Labrary, the place where the library and the laboratory converge to help your software team.

First, Consider no Harmful.

Yesterday, we observed that the goal of considering the go to statement harmful was so that a programmer could write a correct program and have done with it. We noticed that this is never how computering works: many programs are not even instantaneously correct because they represent an understanding of a domain captured at an […]

The unreasonable ineffectiveness of considering things harmful

Dijkstra didn’t claim to consider the go to statement harmful, not in those words. The title of his letter to CACM was provided by the editor, Niklaus Wirth, who did such a great job that the entire industry knows that go to is “Considered Harmful”, and that you can quickly rack up the clicks by […]

Empowered free software

Free and open source software has traditionally been defined as the opposite of something else: proprietary (or commercially-licensed) software. That’s particularly obvious in the name of the GNU project, which calls itself “Not UNIX” – a popular AT&T-owned commercial software property of the time. The GNU manifesto goes deeper on the specific ways in which […]

Pairing in Github

In the world of free software, it’s good to appropriately credit contributors to your community for the work they do. git makes this hard when you pair program. I was at a hackathon recently, and while I didn’t make a single commit, I sat next to a lot of other people who made plenty of […]

Everyone rejecting everyone else

It’s common in our cooler-than-Agile, post-Agile community to say that Agile teams who “didn’t get it” eschewed good existing practices in their rush to adopt new ways of thinking. We don’t need UML, we’re Agile! Working software over comprehensive documentation! This short post is a reminder that it ran both ways, and that people used […]

The feature constraint

If you’re in a purely software business, your constraining resource is often (not always, not even necessarily in most cases, but often) the rate at which software gets changed. Well, specifically, the rate at which software gets changed in a direction your customers or potential customers are interested in. This means that the limiting factor […]

Immutable changes

The Fixed-Term Parliaments Act was supposed to bring about a culture change in the parliament and politics of the United Kingdom. Moving for the second reading of the bill that became this Act, Nick Clegg (then deputy prime minister, now member for Facebook Central) summarized that culture shift. The Bill has a single, clear purpose: […]

On exploding boilers

Throughout our history, it has always been standardisation of components that has enabled creations of greater complexity. This quote, from Simon Wardley’s finding a path, reminded me of the software industry’s relationship with interchangeable parts. Brad Cox, in both Object-Oriented Programming: an Evolutionary Approach and Superdistribution, used physical manufacturing analogies (to integrated circuits, and to […]

Sprouts

Having discussed reasons for change with a colleague on my team, we came up with the sprouts of change. Good software is antifragile in the face of changing: Situation People Requirements Organisation Understanding Technology Society Like any good acronym, it’s really tenuous.

Change

I was just discussing software architecture and next steps with a team building a tool to help analyse MRI images of brains. Most of the questions we asked explored ways to proceed by focussing on change: what if the budget for that commercial component shows up? How would that change the system? what if you […]