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

There&#x27;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.<p>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&#x2F;4 tasks completed and therefore a better product earlier.<p>The fact that this is an article written by a software engineer that completely ignores the missing dependencies bears some irony :-)

It&#x27;s interesting to see this gif used here because it&#x27;s pretty much the canonical explanation of the term &quot;Yak Shaving&quot;[0]. Technical debt is often a cause of yak shaving, so it&#x27;s not unreasonable, but it&#x27;s odd to see such a well-used explainer gif repurposed so.<p>[0] <a href="https:&#x2F;&#x2F;www.davidrevoy.com&#x2F;article861&#x2F;yak-shaving" rel="nofollow">https:&#x2F;&#x2F;www.davidrevoy.com&#x2F;article861&#x2F;yak-shaving</a>

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)<p>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.<p>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.<p>Sorry to be so literal but this is HN. I still thought the clip was funny!

I really like this analogy. Its very prevalent in many teams.<p>Tho I would say experienced developer is able to recognize business needs and how much work has to be put into something NOW.<p>Being able to leave stuff open for fixing later is a crucial skill.<p>I would even go as far as say that not having this skill automatically discredits someone from a Senior position.

&gt; Hal and Lois just illustrated for us what software people like to call “Technical Debt”<p>Wait didn&#x27;t they more accurately illustrate what software people like to call &quot;yak shaving&quot;? 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&#x2F;possible, and each one is further and further from the original goal

I think what could help is using JIRA -like issues-reporting system dedicated not to publicly observable problems (&quot;bugs&quot;) 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.<p>Technically this could be implemented using the same software that is used for bug-reporting.<p>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.<p>From a developer&#x27;s perspective the worst kind of assignment is to try to fix something in a very fragile system because if they &quot;break it, they own it&quot;. Therefore developers love SW quality.<p>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.<p>Using such a system would seem to make a lot of sense to me. Perhaps companies are already doing it?

That scene is FAR better as a video than a gif: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=AbSehcT19u0">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=AbSehcT19u0</a>

&gt; 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”.<p>LOL.<p>Never met a business executive who could be persuaded that tech debt matters. Not one.

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.

I believe the technical term is yak shaving. As in, to get to resolving the original problem you wind up having to shave a yak in order to solve it.

The best time to pay off <i>most</i> debt is: as soon as possible. The sooner, the easier.<p>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.<p>Startups iterate fast because they have the least debt. If you want to maintain your edge, you can&#x27;t let debt grow.

I was just thinking about that scene the other day as I had initially gone in to fix a small bug but ended up staying for a chain of fixes.

Here&#x27;s a classic bit, that sort of says the same thing: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=6oHBG3ABUJU">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=6oHBG3ABUJU</a>

This is the gif I use to explain my ADHD to other people.

&gt; We’ll use an ORM to do data access because we don’t know SQL<p>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.