SIGAVDI #32: More than cartographers

Hello friends, it’s been a while.

Spring is in full flower here at Fair Pavilion. This has been the first year that I’ve been able to really take in the Smoky Mountain wildflower season. Each week I’ve been taking a different one of our kids on a hike in the mountains, working our way up to whole-family hiking days.

Other than that, my spare time over the past two months has been spent on a project I lovingly refer to as “GMST2017”. With my wife recovering from a surgery over the late fall and winter, a lot of things had to be dropped on the floor for a while. This Spring has been my first opportunity to Get My S[tuff] Together, and there was quite a lot of S[tuff] to be Gotten.

As always when re-organizing after a period of chaos, the most difficult part has been taking steps to ensure that my systems will be more resilient next time. It’s a sometimes excruciating process of putting life under the microscope and working-more-to-work-less. But I’ve found that with some imagination, there’s always something more that can be automated, delegated, or divested.


From The Architects Below, by Jessica Kerr:

Retail administration tells us that
every price adjustment should make them type in their password and get approval from a manager. We go to the stores, we observe cashiers adjusting twelve items one at a time — so we increment. We make a way for them to select many items before applying the discount And we get a compromise from retail: only adjustments over 10% require manager approval.

For legibility, we make it so the back office app lets managers see which cashiers make the most price adjustments. Discover fraud; don’t make the cashier make the customer wait.

And then what happens? almost all adjustments are exactly 10%.

Software influences behavior.

This is something I’ve been thinking about a lot lately. There’s a story we tell ourselves as software developers: that we discover the business domain model, like Magellan mapping the East Indies.

This narrative implies that the domain previously had a fixed geography, just waiting to be explored. The truth, more often, is that we participate in constructing the domain model.

How many times have you had a conversation like this with a client/user:

Developer: “Tell me how you do your job.”

Client: “Well…” [10 minutes of explanation, with lots of qualification and backtracking]

Developer: “It sounds like you have a Widget Process that goes as follows. First you…” [5 minutes of prescriptive workflow]

Client: “Yeah, I guess you could put it that way!”

A human work process is, by definition, a purely mental construct. It only exists as a distinct entity inasmuch as it has been given a name and shared among participants. Very often, defined processes and even domain terms don’t spring into being until someone comes along to “discover” and automate them.

And in the process of pinning concrete names and structures to the work, we also change it. Often we change it for the better: greater efficiency, less confusion, better-defined roles. But we should acknowledge our role, not just as cartographers, but as co-creators of the domain model.


Here’s an interesting hypothesis: In software development there are no nuclear reactors, only bikesheds hiding behind other bikesheds.

Via Kevin Rutherford. I’ve sometimes seen discussions get bogged down in what feel like trivial, nitpicky aspects of software design, only to have one of those trivial questions result in an important change emerging.


Gusto is not hiring hackers:

We deal with crucial transactions like paying employees and filing taxes, so we can’t afford to make mistakes. When the priority is moving fast, errors understandably happen. Dropping a few SnapChats won’t have a material effect on anyone’s life (we hope), but if you store a routing number as an integer and dropped the leading zero, an employee might not be able to pay rent.


In a sense, these GitHub notifications are a constant stream of negativity about your projects. Nobody opens an issue or a pull request when they’re satisfied with your work. They only do so when they’ve found something lacking. Even if you only spend a little bit of time reading through these notifications, it can be mentally and emotionally exhausting.

From What it feels like to be an open-source maintainer, by Nolan Lawson.


I’m not going to list all the stuff I published since the last time I wrote. I’ll just note that I’ve been working on an email course on refactoring skills. It’s not so much about concrete techniques as it is about mindset. Justin Weiss says that it’s “amazing”. It doesn’t have a proper landing page yet, but you can subscribe to it for free here.

This week I’m grateful for my Fujitsu ScanSnap iX500 document scanner. It’s not often you get a firmware upgrade for a few-year-old piece of hardware that effectively gives you a brand new device, but that’s exactly what happened with the ScanSnap Cloud update: it went from being a PC peripheral to a standalone smart scanner. Spending $500 on a scanner was a tough trigger to pull, but updates like this make it feel like it was a solid investment.

As always, thanks for reading, and stay in touch.

Happy hacking,

Avdi