←back to thread

127 points leoncaet | 6 comments | | HN request time: 0.738s | 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. pydry ◴[] No.44540803[source]
This is only true in certain contexts. Most of the time software quality is looked over not because it genuinely isnt important but simply because it's hard to perceive.

Ive watched many businesses appreciate the benefits of software quality (happy customers, few incidents, fast feature turnaround) without ascribing it to anything in particular.

Then, when it went away, they chalked up the problems to something else, throwing fixes at it which didnt work.

At no point in time did they accurately perceive what they had or what they lost, even at the point of bankruptcy.

Part of the problem is that the absence of bugs, incidents and delays just feels normal and part of the problem is most people are really bad at detecting second order effects and applying second order fixes. E.g. they think "another developer will fix it" or "devs just need to dedicate more time to manual QA".

Conversely, because it's so hard to see I think it can make a really good competitive moat.

replies(4): >>44541584 #>>44541744 #>>44542490 #>>44543199 #
2. fuzzfactor ◴[] No.44541584[source]
>At no point in time did they accurately perceive what they had or what they lost, even at the point of bankruptcy.

This is traditionally not only with software, but other kinds of companies too.

Some people are just not quality people.

At this conference there's a presentation encouraging "You should finish your software."

If that's all people did that would be 10x better right there.

replies(1): >>44541766 #
3. hinkley ◴[] No.44541744[source]
It’s like physical fitness. Try explaining to someone who has never been in shape how it’ll feel to be in shape, and they won’t believe you.

I’ve converted people by building better systems than they’ve seen before. Some balk, but better than half end up getting it and pitching in.

4. hinkley ◴[] No.44541766[source]
We are getting to the point where people don’t even do the “make it right” part of Make it Work, Make it Right, Make it Fast. It’s making it tough to push for the latter when you can’t even get Right out of some people.
5. esafak ◴[] No.44542490[source]
> ... even at the point of bankruptcy

It that were always the case we could bask in the joy that the problem sorted itself out, but alas, there's a lot of crap that keeps on going.

6. marcosdumay ◴[] No.44543199[source]
> E.g. they think "another developer will fix it"

Ouch. It seems that when a manager sinks some team's velocity by adding a bad developer to it the following reaction is always to add more bad developers so the velocity recovers.

And then when they can't herd all the bad developers around, the obvious next step is to finish destroying everything again by imposing some strict process.