There's definitely a lesson in prioritization in there, as these task are mostly not dependent on each other. Hal already had the light bulb in his hand when he noticed the loose shelf and he already had the tools to fix the shelf when noticing the squealing. The only dependency in there was fixing the car to get WD40 and fix the drawer.
From a business perspective, he could have finished the first two tasks before going to the next one - the total time to completion would be the same, but the business would have had 2/4 tasks completed and therefore a better product earlier.
The fact that this is an article written by a software engineer that completely ignores the missing dependencies bears some irony :-)
> 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.
It's interesting to see this gif used here because it's pretty much the canonical explanation of the term "Yak Shaving"[0]. Technical debt is often a cause of yak shaving, so it's not unreasonable, but it's odd to see such a well-used explainer gif repurposed so.
Is it technical debt though? I always thought of technical debt as being the ongoing problems caused by taking short cuts (specifically: borrowing time from the future to avoid spending time now)
In this example it would have been tech debt if he couldn’t find a light bulb so he plugged a lamp into an extension cord and draped it over the floor… it would work, but eventually someone will trip over the cord.
None of the activities that distracted Hal were essential to changing the light bulb. It wasn’t tech debt and it wasn’t yak shaving. It was just a lack of discipline to do the first job first.
Sorry to be so literal but this is HN. I still thought the clip was funny!
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.
> Hal and Lois just illustrated for us what software people like to call “Technical Debt”
Wait didn't they more accurately illustrate what software people like to call "yak shaving"? I mean sure all of these little problems could be analogous to tech debt ... but the thing that sticks out more than anything is that Hal is shifting from one task to the next, each one to make the previous one easier/possible, and each one is further and further from the original goal
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.
Correct, he didn't need to do them at all. He went off and did them anyway. This is what Yak Shaving is - optional, nested distractions that you engage in and which take you away from a task that you intended to perform. I don't understand what you mean about prerequisites.
In the original yak shaving story, every next step was not an optional distraction but was a prerequisite to doing the previous thing; often caused by 'tech debt' (e.g. the protagonist couldn't borrow the tool you needed from your neighbor because he hadn't fulfilled an earlier obligation, and needed the yak hair to do that)
> [MIT AI Lab, after 2000: orig. probably from a Ren & Stimpy episode.] Any seemingly pointless activity which is actually necessary to solve a problem which solves a problem which, several levels of recursion later, solves the real problem you're working on.
So yeah, both in your first link (mostly) and here: prerequisite - something you have to do, not a side thing like the clip of Hal. That GIF has apparently been misused this whole time, muddying the issue.
(The first link ends with the equivalent of "you can avoid yak shaving by introducing 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.
I think what could help is using JIRA -like issues-reporting system dedicated not to publicly observable problems ("bugs") with the software application, but internal code-design issues which can be seen to possibly cause detrimental issues with software maintenance later. In other words issues which can be categorized as technical debt.
Technically this could be implemented using the same software that is used for bug-reporting.
Then would developers willingly report issues to such a system? I think they would because solving such issues is satisfying to whoever cares about software quality, because it makes it easier to maintain the system in the future.
From a developer's perspective the worst kind of assignment is to try to fix something in a very fragile system because if they "break it, they own it". Therefore developers love SW quality.
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. So yes I think at least some enlightened managers would approve the use of such a system.
Using such a system would seem to make a lot of sense to me. Perhaps companies are already doing it?
(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?"
Right the management would be in charge of course. They would decide whether a given TDEBT-issue should be worked on as a "secondary project" perhaps or not. I think they would still appreciate having the knowledge of the technical debt their company is taking on. You don't need to do anything about (technical or other kind of) debt until you have the money and will to get rid of it. But it's still valuable to know about it I think they would agree.
There's so many kinds of discussions going on in developer communications. Establishing a channel for technical debt within a project would seem to be not the worst waste of time.
I do agree... but I'm a FTE in that's been in my current position for 7 years. I'm not worrying about which way the burn down charts go (and sigh when the estimation is removed - well, at least it's in the history).
The issues that I've had is that as long as there is someone else that is doing the maintenance or support, or the tenure of the developer is closer to the job hopping average - technical debt is ignored at nearly every level.
> technical debt is ignored at nearly every level.
I agree. Technical debt is bad/evil and many (short-sighted) managers try to see no evil hear no evil speak no evil.
They don't want to tell their bosses the software is a maintenance nightmare which will cost the company dearly in the future.
I think we need a new better notion of "code ownership". People who write the code should in some sense "own" it. Only that way they will have a true incentive to make code maintainable and to minimize technical debt. The manager should of course own their shared of the code-ownership. They helped decide what should be in it and what not.
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.
> What hopefully isn’t true in your business is that no-one will ever care about this issue and that it will never be fixed. Instead, I hope you periodically address technical issues brought up during prioritized work and you fix bugs like “Loose shelf in kitchen cabinet”.
LOL.
Never met a business executive who could be persuaded that tech debt matters. Not one.
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.
Whenever I see this clip, my first thought is always that’s it’s a perfect manifestation of my ADHD. Which does of course heavily feature lack of prioritization. To me that false sense of dependent tasks (which in fact, aren’t) is one of the hallmarks.
The best time to pay off most debt is: as soon as possible. The sooner, the easier.
A bad file format, if shipped, will cause decades of debt. Same for critical APIs. Not all debt is this way - you need to identify what debt will multiply and tackle that type of debt ASAP.
Startups iterate fast because they have the least debt. If you want to maintain your edge, you can't let debt grow.
> We’ll use an ORM to do data access because we don’t know SQL
I’m no database engineer, but the whole point of using an ORM is to avoid bare-bones SQL. It’s generally accepted that using an ORM as an abstraction on top of the data layer is a more maintainable solution. At least that’s what we’ve been taught. However, I do believe in writing and knowing actual SQL (for whatever target DB you’re using) so that you can understand what’s actually happening “under the hood”. And many ORMs allow direct SQL passthrough for optimizations, however having an ORM for basic queries like selecting values from a table or view are very welcome and I will always advocate for their usage. I don’t see how this incurs technical debt - in fact I would say just the opposite. NOT using an ORM induces technical debt.
> 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.
I’m willing to admit that perhaps I’m a victim of the Availability Heuristic, but for any Enterprise application I’ve worked on in the past 20ish years, an ORM has almost always been used and in my opinion they has reduced the a lot of the tedium. I wasn’t intending to debate whole ORM vs. SQL thing, but my point is that I don’t agree that using an ORM necessarily incurs technical debt. I also take issue with author’s assertion that ORMs are used because the developers don’t know SQL, as if to say that the SQL-only approach is the valid one, or that developers who use an ORM don’t really know SQL. See also: TypeScript vs. JavaScript, SCSS vs. CSS, etc.
From a business perspective, he could have finished the first two tasks before going to the next one - the total time to completion would be the same, but the business would have had 2/4 tasks completed and therefore a better product earlier.
The fact that this is an article written by a software engineer that completely ignores the missing dependencies bears some irony :-)