A long time ago, when sheet products like sheetrock or drywall became mainstream, they were attached to wood framing using a type of nail. The old sheetrock nails had concentric raised rings along their length called the shank. These fasteners were called, surprisingly, “ring shanked nails“. Go figure.
Fast-forward a few decades and the sheetrock screw was invented specifically for the application of sheet goods, but it soon proved to be so useful for a lot of things in construction that they became ubiquitous.
My story begins with a man named Ed, who was a carpenter and sheet rocker. Ed had mad skills with the sheetrock hammer and nails, and he was so fast and so accurate popping them in, it was impressive. You could hear him working upstairs, bang bang bang. Bang bang bang. He would push the ring shanked nail into the soft paper of the wallboard with one calloused hand and bang bang bang it was sunk to the proper depth, and he had another nail in his hand ready to go.
One day the foreman showed up with boxes of the new sheet rock fastener screws and Ed was required to use them. He was a pretty easy-going guy so no issues, he put the screws in his nail bag and went to work.
Still upstairs they could hear him banging away and when it came to be mid-afternoon my friend went up to see how Ed was making out with the new fasteners.
Ed was actively hammering them in. Bang, bang, bang. He said; “These new fasteners hold pretty good.” This was hysterically funny at the time to a lot of us, and I never forgot it.
This makes me think of technical debt. The software lifecycle is designed with the premise that old outdated stuff needs to be replaced by more performant secure stuff, and it should be that way.
In practice, I think what makes this analogy either funny or infuriating is the time factor involved. We developers can all empathize with Ed, determined to shine despite the unfamiliar territory. On the other hand, if the foreman does not get their crew using the newer standards, the house will not pass inspection later on.
Technical debt can be thought of as what happens when Ed does not pick up the screw gun at all this job and the next, and the foreman does nothing about it. From Ed’s perspective, the hammer is faster and it yields the same result. From an engineering standpoint, the sheetrock screw when properly used adds a lot of structural strength to the wall, but the way Ed is using them negates this. This particular detail did not “trickle down” to the person who was responsible for building the wall, or the one who is performing the work.
We come to this career path for diverse reasons. Some come for wealth, others fame. Some, like me, come because we simply like doing it. I like building stuff and making it work, solving problems and writing code that has some element of Shibui. Getting paid to do what I like is a privilege I value.
We developers all have to take responsibility for making sure we don’t hammer the screw too much. In our business, it’s true that what gives us accolades one year can actually become comical if not ludicrous the next. Technical debt starts with us, in the way we think about what we do. A month or two behind the curve it’s water cooler drama, but when we are 3 years late it feels like waking up in a coffin.
A lot of us don’t have control over how things are built, or if they are built to last. It’s an ethical juxtaposition, if you care about that sort of thing. We can only start with ourselves and look for a place of work that shares our commitment to constant improvement.
If an enterprise is run is such a way as to accumulate technical debt, that is a differing situation but requires a similar solution in my opinion. Continuous focused updates.
We all need only to constantly ask ourselves one question to be eternally viable. Forget about the salary and the stock value. Continuously update your skills and focus on one pertinent query; “Will this position turn me into someone who sometime in the future will be hammering in the screws?”
Bang, bang, bang.
