Keep your code open to possibilities

I’ve been developing software for many years now. Decades. I’ve learned a lot along the way, and I dare to think that I’ve collected some wisdom about software development worth sharing with others. At some point, you think “Yeah, I’ve got a grip on this thing.”And every once in a while, you have some revelation that is the culmination of what you’ve learned along the way. I’ll never forget the moment I understood dependency injection. Of course you would want to pass in an abstraction rather than create an implementation!I had a similar revelation this week. I’m sure there are plenty of sager developers among you who have already figured this out, but it struck me suddenly that really good software design is all about keeping your options open for as long as possible—that you should defer any decisions to the very last minute. 

Now, this seems counter-intuitive. We’ve always been told to plan everything out ahead of time. That we shouldn’t start the project without having thought about every detail that can be thought about. That we need to figure it out now so there are no surprises.

I can just imagine the conversation:Engineering director: “How’s the planning going on the new project?” Development lead: “Great, we’re ready to get started.” Engineering director: “What database did you pick?” Development lead: “Haven’t decided yet.” Engineering director: “Authentication?” Development lead: “Not yet.” Engineering director: “Wait… what?!” 

But the engineering director should be happy with those answers.

Hold out for abstractions

Making decisions early locks you into those solutions, usually allowing the solutions to drive the implementation. Making decisions about implementations drives you away from abstractions. Why abstract something that already exists? I propose that this is exactly the wrong solution. Instead, you should ask the question “What is the abstraction that we need for our solution?” This is the very essence of what I consider to be the single most important thing you can do in software development: Code against abstractions and not implementations. The corollary to this maxim is some advice I tweeted six years ago:

IDG

The revelation for me was that if you think in terms of abstractions, and code against abstractions, you can—and should—defer your decisions about the implementations. The longer you don’t have an implementation, the less likely you are to be limited or driven in a specific direction or decision by that implementation. And the longer you let abstractions drive your decisions, the more likely it is that your solution will be uncoupled. If all you have are abstractions, then you can’t couple to implementations. 

If you decide early on a relational database, and then as the project goes on, it becomes obvious that a NoSQL database is what you need, well, that can be a problem.

Leave the doors open

The goal should be to not even care what database you end up using or which authentication solution you use for your website. Ultimately, it will be easier and more effective to fit your implementation to your abstraction than to try to make your implementation match what you actually want to get done with your project. If the decision becomes moot, then you have created a system that is well-abstracted and thus well-designed.

This also goes a long way towards solving the biggest bogeyman of software development—the unknown unknowns. As long as you don’t have an implementation, you have freedom. The longer you can wait to choose or build an implementation, the greater flexibility you have to adapt to the unforeseen hurdles that will always crop up as you build your solution. 

Deciding early on what implementation to use is like locking a door behind you and throwing away the key. The best software is built by keeping as many doors open for as long as possible, and by allowing yourself to walk back through the door if what you see on the other side isn’t to your liking. Keeping doors open allows you to move forward with more information and less regret.

Now, I realize that the real world enters into this, and ultimately you do have to choose some way to store your data and do your encryption and authenticate and authorize users. This isn’t about avoiding decisions. It’s about making them at the right time—with the right information. The longer you wait to decide the nuts and bolts of those things, the “cleaner” and more decoupled your system will be, and thus the easier it will be to change and maintain down the road.

So if you ever find yourself feeling pressured to lock in an implementation too soon, stop and ask “What’s the abstraction I really need?”

The best software is built on possibilities, not premature decisions.