What a Wedding Taught Me About Software Engineering
I'm too jetlagged to resist silly clickbait
Sorry this newsletter is late! I was at a wedding on Monday and forgot to say "no newsletter this week". As penance for my crimes, I'm going to turn my personal life into content.
One of the nice things about being in software is I don't have to dress up much. I still try to look good at conferences and events, but it's more "shirt jacket over white tee" fashion, not "suit" look-good. This was the second time this year I had to wear a tie and the experience made me wonder: why are fancy clothes so damn uncomfortable?
Lots of reasons, probably, but there's one abstract reason that applies to a wider range of topics than just fashion. "Fanciness" and "Comfort" are both optimization targets. If you don't prioritize comfort, your clothes will be more uncomfortable. Now imagine we take some piece of clothing and measure its comfort and fanciness, then look at all variants of that piece. Some of those variants will be fancier and less comfortable. If your only optimization target is fanciness, you should pick a variant to maximize the quality you care about. If you iteratively repeat the process, you'll eventually end with very fancy and very uncomfortable clothing.1
In other words, fancy clothing is uncomfortable because if it wasn't uncomfortable, we could make it more uncomfortable to eke out more fanciness.
The strength of this heuristic is that it doesn't rely on domain knowledge about textiles or even the details of "fancy" and "comfort". Given any two independent qualities, we can argue that optimizing for one will sacrifice the other. This is also the big weakness of this heuristic: if there's important domain context, or if the qualities aren't dependent, this has the potential to be very wrong. I'd imagine you can't trade off "durability" and "environmental impact", since less clothing waste is more environmentally friendly.
But the heuristic is still useful because of how general it is! It nicely explains to me why optimizations are a source of software complexity: if your targets are "simplicity" and "performance", optimizations are program variants that trade one off for the other. Dan Luu applied a similar heuristic in A puzzle about prestige: "prestige" and "happiness" are both targets, so people can optimize for one over the other.
(To be clear, this is all about when you only care about one thing. You can probably find a good compromise between "prestige" and "happiness", but that job won't be as prestigious as it could be if you were willing to sacrifice happiness.)
Unquantifiable Metrics
We're talking about fanciness/comfort/simplicity/prestige but they're all unquantified concepts. There's no way to measure "simplicity" in the same way you can measure "performance"— people have tried but these metrics are debatably useful at best. How do we optimize for the unquantifiable?
At the very least, there's aesthetic judgement: while we can't do fine-grained "x is a little simpler than y" quantification, but we can roughly identify when "x is a lot simpler than y". That's enough to at least start talking about these kinds of heuristics, since it means we have some mental model of variance, and we don't need to justify "some things are simpler than others".
"Unquantifiable metric" is still an oxymoron, though, so I want a term that's not "metric". "Goal qualities", maybe?
Using the heuristic
Same way for all heuristics: use it to make very low cost judgements or to jumpstart deeper investigations. If simplicity and performance are distinct goal qualities, what do the tradeoff choices look like? Is there a common pattern to them? Is there a conceptual group of "things that trade simplicity for performance" and vice-versa?
What's the proper word for "conceptual group", anyway? Like the conceptual group of "patterns" or "types of concurrency bugs" or "different terms people use for option types"? Okay I'm rambling, time to close this newsletter out. There'll be a less-rushed newsletter next week as normal, bye all!
-
This is basically a hill-climbing argument. ↩
If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.
My new book, Logic for Programmers, is now in early access! Get it here.