The Minimalist Programmer
I’ve always been fascinated by the tiny house movement. I love the idea of living small, making the most of a 100 sq. ft. space, and owning nothing that can’t justify its existence every day.
The thought makes me giddy, honestly. Giving everything at least one job — two or more, if possible. Using a simple pan to grill sandwiches, instead of using a dedicated grill. Using a knife to peel asparagus rather than purchasing a tool specifically for that task. Making do with what you have, and doing without as much as possible.
I like that. But it’s not a lifestyle I can imagine doing all-out with four kids in tow. For now, I do what I can. And I dream.
Recently I was surprised when a friend expressed his love for SOAP. In the circles I frequent, people typically express affection for SOAP about as often as they extoll the virtues of paper cuts and hangnails. When, out of genuine curiosity, I asked him what he liked about SOAP, he explained that he appreciated how the WSDL establishes and enforces a contract, so that both sides understand what is needed and what is at stake.
At this point, I just nodded and moved on, because I could see that we weren’t going to see eye-to-eye on this. Also, I couldn’t quite figure out my own feelings there on the spot, and I needed time to think about it.
So I thought about it. What was it about SOAP, and “enterprise”, and contracts, and WSDL, that made me so uneasy? I don’t doubt that there are use cases where SOAP makes a lot of sense. I don’t question that code contracts are valuable to understand and think about, and can make it a lot easier to reason about your code. But do we really need tools and protocols that enforce these things? Are they really appropriate everywhere?
It came to me that these tools are the electric asparagus peelers of software development. If you need to peel a lot of asparagus, by all means, invest in a tool dedicated to that task. For most of us, though, a knife does just as well. An asparagus peeler would take up space in my kitchen, and make me feel guilty for not using it more. In fact, I might wind up using it for jobs where it was ill-suited, simply because it was there.
Just so — automatically enforced code contracts, and XML-based specification languages, and enterprise-strength service protocols may be just the thing you need, but for most use cases, they’re overkill. They take up space. They bloat your virtual kitchen, and distract you from the focus that minimalism can bring.
(To clarify, I’m not arguing that good software architecture is superfluous. An understanding of code contracts is useful, for instance. I’m simply saying that — using code contracts as an example — a tool that enforces them is not a panacea, and cannot replace a programmer actually understanding contracts. Make do with the tools you have, as much as possible, is what I’m saying.)
It occurs to me that this is very much what Martin Fowler refers to as an “enabling attitude,” and I get that it’s not the only way to view the world. But it seems like it might go hand-in-hand with minimalism. Being an “enabler” (as opposed to a “director”) meshes well with being a minimalist. Fewer guards and tools implies a smaller toolbox, and a tighter application.
As a software developer, the code I’m working in quickly becomes a virtual home. I live there. I may be adding rooms and carpeting, or knocking out walls, or replacing cabinetry, or even just simply repainting, or hanging pictures, but I spend a lot of time there. An uncomfortable or crowded space — virtual or otherwise — is not a pleasant one to be in. I want my projects focused, and tidy. I want every line of code to be able to justify its existence, and work multiple jobs, too. I want the square footage to be as small as possible, without being cramped.
If a tiny house will do, why mess with the increased maintenance and cost of a mansion?