by BrianB on 12/29/22, 10:39 PM with 37 comments
by Sebb767 on 12/30/22, 1:13 AM
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 :-)
by fishtoaster on 12/29/22, 11:30 PM
by doctor_eval on 12/30/22, 7:40 AM
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!
by pojzon on 12/29/22, 11:26 PM
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.
by smcl on 12/29/22, 11:53 PM
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
by galaxyLogic on 12/30/22, 12:43 AM
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?
by Taywee on 12/30/22, 2:47 AM
by slotrans on 12/30/22, 12:35 AM
LOL.
Never met a business executive who could be persuaded that tech debt matters. Not one.
by silversides on 12/30/22, 2:25 AM
by OnACoffeeBreak on 12/30/22, 12:34 AM
by randyrand on 12/30/22, 6:10 AM
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.
by jmugan on 12/30/22, 12:22 AM
by ChrisMarshallNY on 12/30/22, 1:52 PM
by sprkwd on 12/30/22, 4:49 PM
by temporallobe on 12/30/22, 1:22 PM
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.