Hacker News new | past | comments | ask | show | jobs | submit
leoqa | on: AI is forcing us to pay off 40 years of technical debt
I am currently in a stalemate where I have written a proposal that is very technical. The only “business” outcome is that we clean up a massive security mess and rebase on a new consistent architecture.

My manager can’t understand the RFC, and knows that clean up projects aren’t palatable to his senior eng leadership so he keeps asking me to simplify or derive some business justification. I’ve proposed superficial ones like improving security posture etc but he wants a hard number that can be measured (yet another senior leadership mandate).

I’m kind of exasperated and honestly think it’s his job to figure this out.

JTbane | parent | next
You've uncovered the kernel of the software industry- if it works well enough, don't touch it. This is why legacy software hangs around for longer than it should.
asdff | root | parent
You can remove the word software from that and apply it to almost anything. The whole earth rests on legacy temp fixes.
SignalsFromBob | root | parent
Yep. Just like the old saying, "There's nothing more permanent than a temporary solution."
pyrolistical | parent | next
The business value is the savings from the cost of a security issue times its probability
chasd00 | parent | next
If you can't communicate the value of a proposal then you shouldn't be writing proposals. Find an expert and ask them to do it for you.
HPsquared | parent | next
You first need to assess the risk of the current setup, and explain that the new setup will reduce the risk (which you may be able to express in monetary terms).
dumbfounder | parent | next
You really think it’s wrong that you need to show how it will save money in the long run? Why do you care if the software is poorly written? Because you don’t like fixing bugs? Why should they care? If you care then you need to give them a reason to care. I am not saying it doesn’t matter, I am saying you can’t just expect them to agree to do it because you don’t like it. And it seems like that is what you are saying. “Because security” is not an answer. Everything can be made more secure. Show them the risk and impact.
florbo | root | parent | next
It never ceases to amaze me how common this situation is, where a quantifiable compromise is clearly the answer between engineering and leadership, yet none is presented by engineering. No party is ever inherently trustworthy, we all need quantifiable reasons to make decisions. I've never unquestionably trusted leadership, so I've never expected them to trust me.
sensanaty | root | parent
I've been in plenty of meetings with non-technical folk who basically shut their ears off whenever anyone brings up explanations for things like why security matters.

I now work in a highly regulated field (payments/banking) and it's a bit better, but from prior experience if there's no regulator to beat people with, they will simply not give a shit, the only thing they want is to shove out whatever feature as fast as humanly possible.

As an example GDPR was a godsend because I could finally convince people to get rid of the 11 trillion stupid analytics and tracking bullshit we had "Because GDPR", whereas no number of arguments, no matter how well researched and presented, would ever convince anyone before

dionian | parent | next
My feeling is it needs to be communicated non-technically, execs need to think 'what goes wrong if we dont do this', 'how much does it cost'.
preg_match | root | parent | next
I also think it’s fair to expect that non-technical people learn some technical reasoning. They don’t need to be engineers, but IMO it’s completely ridiculous that we just let anyone who is business-adjacent off the hook for not knowing anything.

Business people should understand, at a high technical level, how their products work and what they’re actually asking to implement.

I’ve worked with many great business analysts and product people and consistently the best ones are the ones with the “engineer brain”. They might not know how to read even a single line of code, but they understand software products from their pieces. Those people consistently propose high-quality and feasible solutions. Other business people do not.

As developers, we are expected to constantly think on our feet and adapt. We learn new products and methods on practically a weekly basis. But for whatever reason, the business folk are not even expected to understand the product they help build. There’s such a large disconnect there between dev and business.

IAmBroom | root | parent
THIS is your answer, leoqa. The business value is the $$ the company can lose if it goes wrong.

If higher-ups have no technical insight, round up and give them two numbers: $$ if a bad thing happens, and $$$$$ if the worst thing happens.

skilning | root | parent | next
Yep. I recently had to convince management to let us fix a legacy CloudFormation template that was brushing right up against the AWS resource limit for a single stack (which also means it was WAY over the recommended limit for a production stack). It had been causing CFN to occasionally choke on a deployment for over a year, and it was just a matter of time before we either added the resource that pushed us over the hard limit, or CFN choked on a deployment and failed to roll back to the last good state.

The director of my department kept asking, "But do we HAVE to do this now?", so my final answer was this:

"Do we _have_ to? No, but it's like a bridge. Bridges have an expected lifespan when they're built, and they're supposed to be torn down and rebuilt after that. It's not a HARD limit, though. The bridge doesn't immediately collapse the day after its lifespan, but there are fault accumulating. Metal fatigue, erosion of support material, and other things. Commuters can't tell the bridge is past its lifespan, and they'll continue crossing it every day without issue. And then one day the issues will accumulate to the point that the bridge fails and people DIE. That's the situation we're in with this stack. It will continue to function just fine until the day it doesn't, and on that day I won't be able to tell you how quickly we'll be able to recover the application stack, if at all."

That FINALLY got through to him.

loading story #50368561
loading story #50376496
robotresearcher | root | parent | next
And they’ll ask for the probability of these outcomes to find the expected cost. And you’ll struggle to give one without heavy caveats, and thereby lose perceived credibility.
loading story #50379118
Sharlin | root | parent
Honestly, in traditional engineering firms it’s not the job of the mechanical engineer to quantify risks monetarily, and it shouldn’t be in IT either. It’s other people’s job to turn "without urgent repairs, we’ll have to put severe tonnage limits on this bridge or close it altogether or risk collapse" to the cost of inaction in terms of economic loss.
ericyd | parent | next
You could make an analogy to getting a flu vaccine. There's a small up-front cost, but you're making a bet that it will prevent or reduce the severity of a larger issue down the road. There's no guarantee that the larger issue would ever occur, but "getting the vaccine" makes it less likely to occur, and less costly if it does occur. Skipping the "vaccine" is a reasonable choice if the business is willing to incur substantial damages in the case of a large event in the future. To put hard numbers to it, you could always show numbers like "X% of our customers are likely to leave if we leak all their data to hackers", and base it on documented examples from recent history.
meindnoch | parent | next
Hire a hacker to exploit the security mess.
Woodi | parent
Write them if they do not mandate basic security right their brandy or vodkas or whatever will be served with opposite temperature they expect...