Have you ever been requested to do a change to a system, but that change should not be visible until it is completed? Have you also been requested to launch fixes to the same system while you are changing it? Then you probably faced this problem.

Introduction

We have all been there: someone asked us to add some feature to an existing system, but that it should only be visible when it is completed. You go off and start coding. Sometime later, that same someone asks you to fix a bug, a high priority bug. But you have your code half done, and you can’t simply stash it. How will you handle this?

It was the dawn of computers and software. Operating systems were being developed, and there were still no agreed-upon abstractions. Then came a simple abstraction: the device driver. The device driver enabled the development of software that was not locked to a specific hardware; it allowed developers to write code that worked with any hardware. This seemingly simple change made software development a lot simpler. It is something we take for granted today, but that we forget when we develop software. Why do we keep on forgetting this simple idea? In this article, I’ll explain what the driver abstraction is, how it came to be, and the problems it tried to solve. I will also show why we keep forgetting about it, and the costs we pay every day for not learning from our past.