It's Just Bits

I was talking to a colleague a few months ago about a networking protocol we had to support in a system we wanted to write. We didn't know exactly how the protocol worked, and we knew the library that creates it is about 20 years old. I made a passing comment that the network "is just bits" which caught both of us off guard. No matter how complicated or impenetrable the code may seem, it's just making bits show up in a certain pattern, and in the worst case we can do that by writing it ourselves. It's code, not magic.

This probably came to me because around the same time I was reading the interview with Joe Armstrong in Coder's At Work. A recurring element of Joe's interview is that rewriting things is not as expensive as he feels many believe. He gives an example of wanting to create an X11 library in Erlang. In one case he can wrap the C library, which would reuse a lot of code, but involves calling out to C. In the other, and the direction he decides to go in, he can just implement the X11 wire protocol in Erlang which, he claims, is much easier and safer. It's just bits, why call through a bunch of code that can make his system less stable if understanding the bits isn't actually that hard?

The OpenBSD community exemplifies this in many ways by taking existing solutions and simplifying them. Processing man pages is as old as Unix, and even in the 21st century OpenBSD has taken the time to rewrite the existing solution to be simpler and safer. It's just bits that need to be turned into other bits. Similarly, OpenBSD has introduced doas as an alternative to sudo. While not replacing sudo entirely, doas makes the 99.99% case of what people use sudo for easier and safer. They are just bits that need to be authenticated.

On the other hand, this view doesn't mean one need be nonchalant about rewriting things. JavaScript fatigue has become a common blog point in the last few weeks due to the constant onslaught of rewrites of libraries in JavaScript. In the cases I've given above, the theme seems to be answering the question of "can we do better by writing this?". In the case of my colleague and I, we needed to understand how to, and correctly generate a network protocol, so doing it ourselves would give us the ability make a simpler implementation that was understandable if we couldn't figure out the existing one. OpenBSD often tries to simplify tools, often with security in mind. A rewrite for the sake of a rewrite probably isn't sufficient motivation for people to switch to another tool.

On the opposite side of JavaScript, things that should be rewritten but haven't are tools like Hadoop or webbrowsers, which have had layer upon layer thrown over them to make them not seem as difficult as they actually are but make the whole thing more complicated, and generally worse. Especially in the face of failure. These are big software projects that a lot of people use and, in some cases, require synchronization across a lot of people who are reluctant to change. But there are a lot of ways to generate a report across a few petabytes, or render a web page. Many of them don't require all the complexity that exists and maybe it's worth seeing it for what it is: just bits.

Viewing data and code as the bits they are can be a frustrating or lonely path. You might start to wonder why you have to put up with tool X always breaking. Or why half your time is spent battling framework Y rather than solving your problem. Even if you have determined that you can do better, you may not have the time to execute on it. Or maybe there is some other blocker, such as a manager or network effects. But on the other hand, striking your own path might make you much happier. OpenBSD is not a popular operating system but the OpenBSD developers I have met are some of the happiest. Sometimes it's worth it, but maybe make sure you can do better than what you're replacing in some way.

Author: orbitz
Updated: 2016-06-25 Sat 16:58
Up