[gnagatomo]

>Sometimes that _is_ a business need, but the rest of the business doesn't recognize it (or won't until it's too late).

This. I work for a big payment system company. They had to buy another Exadata, reaching the maximum plan offered by Oracle. The refactor was delayed so much that now we have little more than one year to rewrite everything. If we don't make it in due time no more transactions will be processed. Some devs who pointed the need for a refactor left the company in the last two years and said it feels like a time bomb ticking with every git commit.

Meanwhile the UI/UX guys are trying to create a design system whilst redesigning the internet banking system and app, backed by the CPO and CTO (!?). I mean, I'm not the one calling the shots, but neither a deisgn system nor redesign should be a priority for a least two years.

[mgkimsal]

Yep. I can't say I've worked on data at that scale, but the 'every commit is a time bomb' - had that feeling on things.

What has bugged me in the past (and why I don't like being just a 'coder') is that... hey - people in my position have a perspective few others have. Sometimes we can see things that others can't, and generally we're smart enough to understand the business impact. If you're being asked to implement 'business logic' all day, for months or years, at some point, whether you want it or not, you can see how a business is being impacted by things that you can see. Raising a flag like "hey, xyz should probably be a priority..." and being dismissed because you're just a coder and don't understand the business - besides being insulting, sort of doesn't really jive with reality. In many cases, the software team are the only people that actually have a strong understanding of 'the business' - how many of the pieces fit together, etc.

[gnagatomo]

>you can see how a business is being impacted by things that you can see

Strongly agree. The biggest barrier between devs and refactors with zero interface impact is AGILE mentality of always aiming to deliver value to the end user with every deploy. Business people just don't understand how much of an impact crappy implementations and error handling does have on the end user. We see 5~6% error rate, which represents hundreds of thousand of people daily, but shipping a new "feature" (that within months will be used by a few hundred people with a very high bounce rate) is always the top priority.

From time to time there is a meeting with the following subject: "why are users not using the basic features", and the business people's answer is always "the ui is outdated" or "the menu is confusing the user". Those answers are gathered by talking to some random users on the streets close to the company building (I'm not making this up).

[mgkimsal]

> We see 5~6% error rate, which represents hundreds of thousand of people daily, but shipping a new "feature" (that within months will be used by a few hundred people with a very high bounce rate) is always the top priority.

seems to get back to "what gets measured" mantra. And, reminds me cell phone company churn. There's loads of things that could be done to improve service for existing customers, but companies spend budget chasing 'new' customers to 'switch' with low rates for X months, then jack up the price. "Loyal" customers get ignored.

[bobblywobbles]

And then you end up with brittle applications to support. Not fun for devs. Not happy times with management.