[Raidion]

I would also argue that software (and the people that write it) have a "correctness" bias that is not fully aligned with business goals.

Tech debt is real, but so is the downside of building a system that has constraints that do not actually align with the realities of the business: optimizing for too much scale, too much performance, or too much modularity. Those things are needed, but only sometimes. Walking that line well (which takes some luck!) is what separates good engineering leadership from great engineering leadership.

[disgruntledphd2]

> I would also argue that software (and the people that write it) have a "correctness" bias that is not fully aligned with business goals.

Hey, I resemble that remark!

Yeah, I get where you're coming from but i do really feel that it's more of a communication issue, along with the abstract nature of software. I mostly do data related stuff, and have often had the experience of finding "wrong" data that doesn't have a large impact, and every time I need to remind myself that it might not matter.

You can also see this in the over-valuation of dashboards vs data engineering. Stakeholders lurve dashboards but value the engineering of pipelines much less highly, even though you can't have dashboards without data.

[hjeepn]

To be fair, this bias for "correctness" is both logical and necessary, and not something that stems from inability or unwillingness to understand business goals.

That tech debt you took on to meet the latest oh-so-important deadline? Prepare to live with it forever, because the next hare-brained initiative is right around the corner.

Frankly, the business's goals are not my goals, and unless I own the place, I'm not sacrificing good work for it.