code development programming

Abstractions are scaffolding

All software is an abstraction. It’s human-like language with a logical structure to abstract over ill defined business processes, and gates and transistors, and assembly language, and often 7 network layers, and memory management and databases and a myriad of other things that abstractions paper over to help you deliver business value.

Abstractions are the scaffolding you need to get your project running, but they’re another dependency you need to own. You need to understanding what’s under the abstraction. Or you start thinking network traffic is free. The network is not your friend, it’s slow and unreliable.

Abstractions provide some structure to make what they support easier, but they in turn rely on structures underneath. If you’re going to own an abstraction like any other dependency, you need to understand the structure it’s built on and what it’s designed to support. I understand what ORMs do because I’ve written some of that code in a less performant, less reliable way, before I realised someone had done it a lot better. Indeed, that was the realisation that drove me to alt.Net and NHibernate, but it meant that I understood there was SQL underneath, and the SELECT N+1 problem was a mismatch in the queries that could be resolved, and not just an unexplainable performance hit caused by a network spike.

Abstractions make more sense if you understand what they’re abstracting over. They’re not there for you to forget about what’s underneath, just to save you having to write that code for every class in every project you work on, and to benefit from a wider pool of developers working on battle-tested code. If you don’t know TCP from HTTP, don’t write web applications. If you don’t understand databases or SQL, don’t use an ORM.

All abstractions are imperfect. Learn what’s under the cracks.

8 replies on “Abstractions are scaffolding”

That was actually something I explored in an earlier draft, so maybe I should come back to it. Should we treat these abstractions as temporary? I worked on a system that used nhibernate against a local database then migrated to a client-server model that made many of the assumptions invalid, so we had to rewrite the orm handlers to respect the new world.

Abstractions should be more open to change, because that’s the outside world. That’s what you rewrite to move to the cloud, or to mobile, or to port to 64-bit Windows. If you treat them as temporary, you’ll keep them at arms distance so you can replace the abstraction without large disruptions to your business logic.


I agree that the abstractions need to be mutable and should follow principles that allow for encapsulation, etc…

But “temporary” in the sense that “they will completely go away” I find to be false. For example you mentioned the abstractions between source code and “gates and transistors” (the former typically, but not always implemented by the latter in current hardware).

If that abstraction is removed from the thought process [such as scaffolding is removed from a building once construction is complete], then we would end up with developers using oscilloscopes to probe the individual electrical nodes to debug their programs.

Fortunately that is something the vast majority of developer will never have to do. For better or worse, there are times I need to drop to that levels, with my 1968 DEC (though I have not had to do it for professional work since the late 1970s).

Liked by 1 person

It will take a while for transistors to go, I admit, but I’m surprised at how dramatic the change has been since we could pretty much rely on having x86/64 hardware under the hood, whereas there’s now a mash of ARM and other chips for a variety of services.


I am not talking about “transistors going away”. I am talking about the abstraction (many layers) between what we think of as “the code” and the actual transistors being an inherent part of the ecosystem and not something that goes away – eliminated totally – when the work is complete. How if “abstraction is scaffolding” then the abstraction would, by definition, be something that did go away. QED: abstractions are NOT scaffolding.


Yeah, I agree with the point. As I said, I had discussion about temporary structures in an early draft, but it wasn’t sitting right. This discussion helps me understand why. I’m not sure what the correct analogy is. Skeleton maybe.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.