Most active commenters
  • hinkley(4)
  • wiseowise(3)

←back to thread

131 points leoncaet | 15 comments | | HN request time: 0.336s | source | bottom
Show context
burnt-resistor ◴[] No.44539155[source]
I'm disillusioned because it never happens, but purveyors of conferences and books are happy to sell the promised land™ of how "it's really going to be different this time."

Processes, tools, and diligence vigilantly seem the most apparent path. Perhaps rehash the 50 year old debate of professionalization while AI vibes coding is barking at the door, because what could possibly go wrong with even less experience doing the same thing and expecting a different result.

replies(3): >>44540097 #>>44540223 #>>44540697 #
rachofsunshine ◴[] No.44540697[source]
It doesn't happen because building the best software is not the goal of a software engineering job.

If you want to do that on your own time, that's fine - but the purpose of a job is economic. Of course you should write software of some reasonable quality, but optimizations have diminishing economic returns. Eventually, the returns are lower than the cost (in time, money, etc) of further optimizing, and this break-even point is usually at a lower level of quality than engineers would like it to be. Leadership and engineering managers know this and behave accordingly.

replies(3): >>44540744 #>>44540803 #>>44540961 #
1. astrobe_ ◴[] No.44540961[source]
Companies can sacrifice every thing for "time to market" - optimization, maintainability, security and safety even - but underestimate the costs of doing that. It is actually more a marketing choice than an economic choice.

One can be skeptical about the implied statement and leadership/management knows what it is doing beyond delivering at the (arbitrarily) set time. One definition of Quality is to satisfy a need entirely at the lowest cost in the shortest time, but more often that not, the last term gets 90% of the attention.

replies(3): >>44541227 #>>44541727 #>>44542153 #
2. wiseowise ◴[] No.44541227[source]
> but underestimate the costs of doing that

Do they? I’ve been fighting against the tide for years until I understood that all of quality this and quality that doesn’t matter. Sure, it sucks to be on the receiving end of buggy software, but this where you vote with your money. At work? Finish the task with least amount of resources and move on.

replies(3): >>44541734 #>>44541755 #>>44542471 #
3. hinkley ◴[] No.44541727[source]
They underestimate how long it takes to turn the boat when lowering operational costs becomes the best avenue to improving revenue.

I think it’s like switching CEOs when the company goes out of startup mode into grownup company. What got you here won’t keep you here.

4. hinkley ◴[] No.44541734[source]
It’s about momentum. Once you lose it the wheels come off. And at first that’s shipping product, but later on it’s adding new features to the minefield you’ve laid. Until you start clearing the mines your velocity continues to drop.
replies(2): >>44541767 #>>44541840 #
5. anonzzzies ◴[] No.44541755[source]
> Finish the task with least amount of resources and move on

which is now claude code...

6. wiseowise ◴[] No.44541767{3}[source]
> Until you start clearing the mines your velocity continues to drop.

I've been doing this for decades, it's never a problem. Either velocity tanks in which case there's a short period where company invests into improving it, or people leave.

replies(1): >>44542395 #
7. ◴[] No.44541840{3}[source]
8. akst ◴[] No.44542153[source]
> Companies can sacrifice every thing for "time to market" - optimization, maintainability, security and safety even - but underestimate the costs of doing that

If you're working at a company who disregards safety and security good luck getting them to care about clean code and efficiency.

9. rizzom5000 ◴[] No.44542395{4}[source]
I've seen projects that failed, or were killed, likely at least in part due to a culture that encouraged poor quality and tech debt. This is preventable, and for no additional up-front engineering effort or time investment.
replies(3): >>44542817 #>>44542866 #>>44543070 #
10. esafak ◴[] No.44542471[source]
At work the buyer is not the user, so be sure to hound the buyer when he saddles you with crap.
11. hinkley ◴[] No.44542817{5}[source]
One of my managers was fond of the phrase, “a project is done when nobody is willing to work on it anymore.” That can be because of a number of reasons, including that the money is gone, or it sucks your will to live.
12. astrobe_ ◴[] No.44542866{5}[source]
Yes, parent says "people leave" as if it is not a problem in itself; you lose the time it takes to train these people, and they probably take some knowledge about the products with them. Or maybe we are actually talking about commodity developers?

But I'm curious about how one prevents this dysfunctional culture.

replies(2): >>44542946 #>>44544101 #
13. hinkley ◴[] No.44542946{6}[source]
At my last job the people motivated to fix the clusterfuck were the first to leave. Except me because I’m a masochist apparently.
14. switchbak ◴[] No.44543070{5}[source]
I think this is the most common failure mode I’ve seen, short of a failure to find a proper product-market fit.

It’s just really hard to overstate how much damage a bunch of crappy code can have. Even with the best of intentions. I must say I strongly disagree that this is “never a problem”.

15. wiseowise ◴[] No.44544101{6}[source]
We’re talking about different scales.

At a big company “you” don’t lose anything. You only lose if you’re a fool trying to fix dysfunctional culture when you’re not even close to C level.