Regular Programming podcast is officially on summer break. It has been wildly inconsistent due to logistics and our respective lives but we fully intend to continue it but there’s no way it is happening right now :)

Otherwise, nothing much going on. If you company want my help reaching the Elixir community and recruiting Elixir developers, reach out. More fuel on that fire as August rolls up.

Trade-offs and abstraction

I’ll credit Chris Keathley with offering me a clear example on what a successful design in tech can look like. The network stack. Most of the time developers do not have to think about the details of TCP, UDP or IP. We have an IP address, a port number, a protocol and we can do our thing. The network stack is not front-of-mind context for me to implement my Phoenix controller. I don’t need to think about it. This can be considered an example of a good and successful design.

Certainty and confidence are two different but related things. If you are certain about something you are fully confident. You can be quite confident without being certain. Certainty is an absolute of confidence.

From what I’ve seen it is generally accepted in the abstract that one should minimize friction in software development. Agile makes claims to that. CI/CD makes claims to that. In practice many companies get very uncomfortable about removing or automating gates. Often quality gates but sometimes they are just about authority, approval and responsibility. ”It has to go through QA.” or ”We need the boss’ approval” are common gates. This introduces friction to arguably raise confidence or get at least political certainty.

If you read the book Accelerate it certainly indicates that friction is almost always the wrong thing. Releasing often and fixing things quickly being more important than avoiding mistakes for overall outcomes. That’s the argument of that book.

Bring this conversation to developers and they’ll break down on varying sides of this and to varying degrees. We have this trade-off everywhere. A dynamic language like Elixir has very low friction for doing your thing but gives you no certainty about correctness. A language like Rust trades in more up-front friction for more certainty about correctness. Elm does that as well, in a somewhat different manner. Defendants of dynamic languages will argue that it slows them down to faff around with types and correctness. Proponents of statically powerful languages will usually argue it doesn’t slow you down and makes for more reliable results. Development speed is a very tricky thing to know so I won’t argue about it. Those stricer languages do introduce friction. Intentionally.

And this is I think is a design thing. When you introduce friction you should be well aware of why you are doing it. Your compiler shouting at you because you haven’t satisfied some part you aren’t done with is friction. Rust, Elm and many other languages trade some friction for some level of certainty (or very high level of confidence). I think this is one of the most fair circumstances to introduce friction. When you can introduce a system which can say ”what you are doing is wrong and will be a problem”, that’s useful and potentially powerful.

It is not as low-friction or clear-cut in trade-offs as the network stack. But you get a valuable level of confidence or even certainty for a trade-off in friction. This makes sense as a design decision even if it might not be the right design decision in every case. It is similar to how it is generally accepted that a database should be somewhat strict and we expect it to offer some fairly strict guarantees. It is very common to accept that we need to create a schema and deal with those constraints and errors in code. We’ve also seen NoSQL in large part throw that out the window. Same trade-off.

I think where friction trades off much worse is where it only provides a low-to-medium degree of confidence. Well-considered tests that give a lot of confidence are well worth having and building out. Full test coverage is very likely not and introduces friction to processes that would be fast without that requirement.

The same thing with human gates in the process. Reviews, QA passes, sign-off. Typically friction with iffy and unclear confidence gains and absolutely no certainty. Essentially you are slowing down for an unclear amount of confidence and absolutely no certainty. Unless it is for compliance in which case it provides the certainty that the stamp has been stamped and in some way is worthwhile.

There is essentially no trade-off consideration needed for deciding to use the network stack in your work. There are many other things we lean on that we don’t really have to consider or design ourselves. Overall though, we have to consider whether we are putting in meaningful gates that give a valuable amount of confidence and certainty or whether we are just slowing ourselves down for little gain.

Let me know your thoughts at lars@underjord.io or on Twitter where I'm @lawik.

I appreciate you. Thank you for your time.

- Lars Wikman