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

31–40 of 40 posts

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

#31

Post by rzzzt »

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…

> 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

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

#32

Post by anenefan »

Sebb767 wrote: post #12

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

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.

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

#34

Post by temporallobe »

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

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

#35

Post by lloeki »

Sebb767 wrote: post #12

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

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

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

#37

Post by djbusby »

Sebb767 wrote: post #12

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

I thought he was holding the burnt out bulb.

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

#39

Post by kwhitefoot »

temporallobe wrote: post #34

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

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

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

#40

Post by temporallobe »

kwhitefoot wrote: post #39
temporallobe wrote: post #34

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

> 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.
Post reply on HN