Arch-Engineer
Hello, it's Jimmy!
We've all heard that writing good software is something that can only be learned experientially, or perhaps even that good programmers are born, not made. And yet we also keep hearing about principles that underly good code: information hiding, modularity, cohesion, lax assumptions. I've spent much of the last few years trying to figure out how to break these concepts down and teach them. This is my newsletter where I occasionally share readings and ideas with new insights about designing better software.
In my other life, I'm a researcher in automated programming tools. I believe these two things are related, with idea flow in both directions. When you understand how to break down and articulate software principles, it's easier to formalize them and put them in automated tools. Conversely, every automated tool contains some insight about programming. And, of course, if you're trying to improve yourself as an engineer, you could benefit by being the first to know about programming tools that can do some of the tricky parts for you.
As with every new endeavor, things are still being figured out. Expect everything to change over the coming months at Arch-Engineer, including the name itself.
The Secret of Fast-Programming: Stop Thinking
This is where I'll be sharing a monthly reading that shares some insight into good software design, beginning with Max Kanat-Alexander's provocatively titled post The Secret of Fast-Programming: Stop Thinking.
As usual when I read a blog post, my take tends to be much higher-level and more technical than the author's. The goal of every line of code is to make some fact true. The complexity of the code hence follows from how hard it is to establish a fact from what is already true.
What are the things that are already true? Typically your data structure invariants. What fact are you trying to make true? Typically the assumptions made by some other function. Simple code hence follows easily when different parts of your code make simple assumptions, and when your data structures are designed in a way that makes them easy to satisfy. Trying to create simple code when the underlying conditions are complicated is like trying to shape the water around the Mariana trench into a perfect sphere: it just doesn't fit.
The idea is not that, if you simply stop thinking, you'll have better code. The idea that, if you find extensive thinking is frequently necessary when working on your codebase, you may want to rethink your design.
Research Corner
Super-optimizing Legacy Code with Helium
For our first Research Corner, I'd like to highlight the Helium project created by my friend Charith Mendis in the COMMIT group at MIT.
Running a filter on a 100-megapixel image is expensive, and so Adobe engineers have spent months parallelizing and optimizing each filter in Photoshop. Problem is, Photoshop is now about 30 years old, and they can't keep repeating this every time the processor changes.
Helium solves this by automatically extracting the core algorithm used by the filter, and putting it into a high-level form. Combing this with their existing Halide language for high-performance image-processing code, they were able to accelerate filters in Photoshop by up to 75% (and higher for other programs).
Although most of us don't write hyper-optimized image-processing code, there are a few lessons to be learned as engineers. It's long been known that it's easier to understand a program by looking at the relationships between data structures than by trying to follow the code. Helium embodies this in automated form. They key thing it must do is reverse-engineer the image-processing pass, and extract the computational core, called a stencil kernel. Because analyzing the optimized code and following the control-flow is too difficult, it instead tracks the data-access patterns. Doing so, it essentially builds a snippet of a dataflow graph, from which the stencil kernel falls out immediately.
For more information, check out the Helium website.
