Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mikesteder.com

Post reply on HN
Print view View original

11–20 of 40 posts

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

#11

Post by Izkata »

smcl wrote: post #4

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

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.

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

#12

Post by Sebb767 »

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

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

#13

Post by shagie »

galaxyLogic wrote: post #8

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 b…

(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?"

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

#14

Post by [deleted] »

smcl wrote: post #4

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

[deleted]

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

#15

Post by galaxyLogic »

shagie wrote: post #13
galaxyLogic wrote: post #8

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 b…

(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…

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.

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

#16

Post by smcl »

Izkata wrote: post #11
smcl wrote: post #4

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

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.

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

#17

Post by shagie »

galaxyLogic wrote: post #15
shagie wrote: post #13

Earlier quoted context omitted.

(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…

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 a…

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

I occasionally think about how to implement PEF/REV ( https://www.fincher.org/tips/General/SoftwareDevelopment/Bug... - though https://lostgarden.home.blog/2008/05/20/improving-bug-triage... is another approach) in Jira (long ago, I was part way through implementing it as a plugin in Redline).

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.

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

#18

Post by PeterisP »

slotrans wrote: post #7

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

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

#19

Post by PeterisP »

smcl wrote: post #16
Izkata wrote: post #11

Earlier quoted context omitted.

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)

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

#20

Post by shagie »

PeterisP wrote: post #19
smcl wrote: post #16

Earlier quoted context omitted.

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)

Don’t Shave That Yak! - https://seths.blog/2005/03/dont_shave_that/ (this is the original with the borrowed EZPass)

2020 https://news.ycombinator.com/item?id=21930441 (81 comments)

Don’t shave that yak – God loves lazy programmers https://petewarden.com/2010/06/26/dont-shave-that-yak-god-lo...

2012 https://news.ycombinator.com/item?id=4034034 (3 comments)

Post reply on HN