I'm just trying to change this lightbulb (2014)

> The fact that this is an article written by a software engineer that completely ignores the missing dependencies bears some irony :-)

I don't think this is the case as the author mentions he assumes Hal follows the boyscout rule:

> at each step of the process leave the camp site a little bit nicer than it was when arriving

Which is the only way to get tech debt under control when tech debt is not a dedicated project (and thus receives no allocation)

It kind of punts on the dependency thing, the idea being that if you notice some small fixable thing then you might as well do it right now.

Which in turn makes the parallel with tech debt all the more on point, the joke being not so much about a singular chain of issues but about the household being absolutely drowned under a gajillion independent issues that keep making everything demoralisingly slow.

Strangely I'd refer to the situation described as spreading oneself too thin (on jobs that could wait but need to be done) ... or if working for yourself, and the light that needed replacing, was in fact something they knew to be very unpleasant or tedious, avoidance therapy.

I think it would closer reflect technical debt if when Hal went to change the light he found the shade needed cleaning badly, he wipes it down with a damp cloth, the top of it is filthy, but as he wipes he can bits of the shade are coming off in the wet rag, then he gets a mild shock when he wipes the cord hanging from the ceiling. It obviously no longer meets the safety code as it is unsafe and decides since he needs to hold onto it while replacing the shade, it needs replacing and needs to ensure the power is off first ... before he gets the fortuitous spare cord he realises the fact he got a shock while the light was supposed to be off means the switch needs to be inspected, and resolve the dilemma. In the mean time Lois arrives and realises the shade is see though in places and mentions it needs to be replaced why aren't they doing that. Hal who's pulling the switch cover off carefully exclaims what does it look like I'm doing.

I thought he was holding the burnt out bulb.

Exactly. There’s no reasonable world where the kitchen lamp should remain out while you (try to) drive to the store.

Pop the stack a few levels, replace the lamp, then decide if you need more WD-40 right now or can get some the next time you’re out.

sure. and when you're done they throw a new project at you with another arbitrarily tight deadline and it never gets fixed. that's how we accumulate the debt, because we are focusing on the crucial things.

The way I understand it, yak shaving involves prerequisites. But Hal didn't actually need to do any of those things, they were side issues he found but could have ignored - which is a better fit for technical debt.

> Situation: You have a push-down stack for all your goals. When you hit an obstacle, you push "remove the obstacle" onto the stack. Then, when the obstacle is cleared, you pop the stack, and you are back at your original problem.

> Problem: For some reason, the problems you push onto the stack keep getting bigger and bigger and bigger, dwarfing the original problem, each one dwarfing the one before it.

http://wiki.c2.com/?PushDownGoalStack

(realizing I'm being a bit of a downer on this...)

Adding to the total "estimated time" for a project in Jira at some places is a "bad" thing. It makes the burn down chart go the wrong direction.

This also presupposes that a developer cares about the long term maintainability of the code. When tenures are measured in "two years? You've been there for a long time" the work that needs to be done two years and a day out isn't something that is a concern.

There is a lot of "development team did it, it's done, throw it over the wall and let the maintenance team deal with it." The maintenance team, however, is under resourced and since there aren't any good tests for the functionality, refactoring anything that isn't verifiable is much more work than fixing a bug where you can say "yep, that's done."

Management in many places isn't concerned about code quality and see it more as "developers are gold plating that project." Spending 4h to reduce the time it takes to do a hypothetical support ticket that may never occur from 3h to 1h of maintenance time (that's a different team) isn't a good investment of time.

And while there are enlightened managers out there, they are still up against the metrics of "how much did your team accomplish that the business wanted?"

    But would management approve of spending time on reporting and possibly
    fixing design issues? Well why not because if the knowledge of the issues
    exists only in the head of some developers, it is not really owned by the
    company. Whereas if it was reported in an issue-tracking system it would
    become official part of the IP owned by the company, increasing its value.

In practice, management will not endorse developers reporting and spending time working on design issues, unless that design issue can be directly identified as a blocker impeding the delivery of urgently needed functionality. Even then, half the time the developer will be told to note the issue and implement a short-term workaround.

    Using such a system would seem to make a lot of sense to me. Perhaps
    companies are already doing it?

Pretty much every company I've worked for has had a category in JIRA for design issues and technical debt. Tracking these things isn't the problem. The problem is getting buy-in to spend a portion of each sprint actually addressing these issues, rather than having them in some backlog pile that everyone pays lip service to, but no one takes action on actually reducing.

If in your business it's quite likely that the equivalent of that 'kitchen cabinet' is going to be replaced, or simply become unused, or that you're going to switch to an entirely different house with different cabinets - then it becomes obvious that in those scenarios spending time and effort on bugs like “Loose shelf in kitchen cabinet” may be totally counterproductive. Essentially, it's the YAGNI principle on a bit higher level of abstraction, where the default assumption (and not that unwarranted) is that whole tech systems and/or business processes often are short-lived, disposable and actually disposed of.

> It’s generally accepted that using an ORM as an abstraction on top of the data layer is a more maintainable solution.

Not in my experience. Unless there has been a radical shift in opinion in the last five years I would say that that was quite a controversial position.