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

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

99 points by BrianB 3 years ago | 37 comments

Sebb767 3 years ago |

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 :-)

lloeki 3 years ago | |

> 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.

anenefan 3 years ago | |

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.

m463 3 years ago | |

https://wondermark.com/464/

psnehanshu 3 years ago | | |

Broken SSL

djbusby 3 years ago | |

I thought he was holding the burnt out bulb.

fishtoaster 3 years ago |

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.

[0] https://www.davidrevoy.com/article861/yak-shaving

doctor_eval 3 years ago |

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!

pojzon 3 years ago |

I really like this analogy. Its very prevalent in many teams.

Tho I would say experienced developer is able to recognize business needs and how much work has to be put into something NOW.

Being able to leave stuff open for fixing later is a crucial skill.

I would even go as far as say that not having this skill automatically discredits someone from a Senior position.

sokoloff 3 years ago | |

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.

8n4vidtmkvmk 3 years ago | |

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.

smcl 3 years ago |

> 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

Izkata 3 years ago | |

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.

smcl 3 years ago | | |

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.

rzzzt 3 years ago | |

> 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

galaxyLogic 3 years ago |

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?

Taywee 3 years ago |

That scene is FAR better as a video than a gif: https://www.youtube.com/watch?v=AbSehcT19u0

slotrans 3 years ago |

> 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.

PeterisP 3 years ago | |

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.

silversides 3 years ago |

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.

OnACoffeeBreak 3 years ago |

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.

randyrand 3 years ago |

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.

jmugan 3 years ago |

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.

ChrisMarshallNY 3 years ago |

Here's a classic bit, that sort of says the same thing: https://www.youtube.com/watch?v=6oHBG3ABUJU

sprkwd 3 years ago |

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

temporallobe 3 years ago |

> 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.

kwhitefoot 3 years ago | |

> 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.

temporallobe 3 years ago | | |

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.

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.