Jonathan Waldman
Engineering
I write software for a living. But my major headache isn't writing it; it's maintaining it. Software, like any other engineered object, is subject to corrosion.
No, it doesn't literally corrode. It just behaves as though it does. Take a working piece of code. Leave it for six months. Try to run it. You'll almost inevitably find that something has changed. A file isn't where it used to be, or its format has changed, or the database is different, or something that I'm depending on doesn't work the same way, or a calculation has changed, or some assumption is invalid, or ... the list is endless.
The process is sometimes called "bit rot".
So I really liked Rust. Entropy is an absolutely inescapable portion of any engineer's life. It's manifestly stupid not to plan for it--and yet many engineers (or organizations) don't. Rust explains, in gory detail, why they're wrong. Plus I'm a sucker for any kind of book that takes some overlooked aspect of our world and delves into it.
I have a couple of quibbles. The chapters are individual essays--stories of people who are involved with corrosion in some way, including a pipeline engineer and an artist. They don't really link up into an overarching story. I wouldn't have minded more chemistry and physics, either.
Quibbles aside, though, this is a fine read. A couple of other books of the same sort spring to mind:
- Does the subject of the now-ubiquitous shipping container sound boring to you? Then you haven't thought enough about it; read The Box, by Marc Levinson.
- Similarly, does a book about human waste sound like something to make smirking jokes about? After you read The Big Necessity, by Rose George, it won't seem very funny.
You are right in that most organizations don't plan for entropy, or change, as I would put it. Most people are actually rewarded for it, strange as that may sound. A good friend of mine at work who is a software developer (actually, not just software, also an infrastructure engineer and linux admin) and I were in the camp of building robust tools. It seemed that the rest of the organization was in the camp of get-it-done-fast. Quick and dirty has its place. There is something to be said for a bias for quick action.
ReplyDeleteQuick action is rewarded, because it is visible, and it is solving an immediate, critical need. Robust tools are not, because they are, by their nature, not visible. They get the job done, day in, day out. What most people fail to see is that the reason we have the critical need is more often because we didn't take the robust route to begin with.
I struggle with this as well. The ideal circumstance in my world would be to do something quick, figure out what worked, go back and change stuff, figure out what worked, repeat. My organization is good at the "let's get something done for the short term" part, but not at the "... and then go back and fix it later."
DeleteAnd, yes, we're rewarded for it.