←back to thread

1070 points dondraper36 | 5 comments | | HN request time: 0.477s | source
Show context
hinkley ◴[] No.45068652[source]
One of the biggest, evergreen arguments I’ve had in my career revolves around the definition of “works”.

“Just because it works doesn’t mean it isn’t broken.” Is an aphorism that seems to click for people who are also handy in the physical world but many software developers think doesn’t sound right. Every handyman has at some time used a busted tool to make a repair. They know they should get a new one, and many will make an excuse to do so at the next opportunity (hardware store trip, or sale). Maybe 8 out of ten.

In software it’s probably more like 1 out of ten who will do the equivalent effort.

replies(5): >>45068811 #>>45068978 #>>45069113 #>>45069475 #>>45070924 #
1. fuzzy2 ◴[] No.45068978[source]
From somewhere around the net, I found this quote:

> It's not enough for a program to work – it has to work for the right reasons

I guess that’s basically the same statement, from a different angle.

replies(2): >>45069111 #>>45069174 #
2. soperj ◴[] No.45069111[source]
I remember once having to make a SOAP call that just wasn't connecting for some reason, but another end point on the same service was working, which made no sense. We tried calling the working endpoint right before calling the busted endpoint just for kicks, and that actually functioned. Still to this day makes no sense at all to me, we ended up moving off of soap eventually, but that code was in there until we did.
replies(1): >>45069157 #
3. hinkley ◴[] No.45069157[source]
I hate the days when you are trying to fix a bug in a block of code and as you write pinning tests you realize that the code has always been broken and you cannot understand why it ever got the right answer. You’ve let the magic smoke out and you cannot put it back without fixing the problem. At some point you have to stop trying because you understand perfectly well how it should work and you need to move on to other things.
4. IshKebab ◴[] No.45069174[source]
I generally agree, except if the program is a one-time program meant to generate a single output and then you throw it away.

Until recently I would say such programs are extremely rare, but now AI makes this pretty easy. Want to do some complicated project-wide edit? I sometimes get AI to write me a one-off script to do it. I don't even need to read the script, just check the output and throw it away.

But I'm nitpicking, I do agree with it 99% of the time.

replies(1): >>45069611 #
5. hinkley ◴[] No.45069611[source]
I often write those sorts of tools iteratively.

By the time you’ve done something five times, it’s probably part of your actual process, and you should start treating it as normal instead of exceptional. Even if admitting so feels like a failure.

So I staple something together that works for the exact situation, then start removing the footguns I’m likely to hit, then I start shopping it to other people I see eye to eye with, fix the footguns they run into. Then we start trying to make it into an actual project, and end game is for it to be a mandatory part of our process once the late adopters start to get onboard.