Hacker News Reader

Comment by GordonS | Hacker News Reader

> But that is not how software is done. I want outcomes not masses. I need creativity to work on tools expressed through software not cheaper developers.

Fully agree, but the people making the decisions at large corps are not developers, and are just as focused on costs as the Indian outsourcing firms pushing low cost devs. And in turn, those people are pushed by the board to make cost reductions, and board members understand this even less.

As a developer and architect, I've had this discussion many times over my years working in the enterprise space, and it always ended with me throwing my hands up and giving up.

View on HN

Non technical folks under-appreciate the cost and frequency of long-term technical debt.

It's easy to save money on developers, yet very quickly produce a net-negative result for the company.

Sadly, few companies have guardrails to prevent these sort of shortsighted choices. E.g. requiring parallel approval of projects by IT architects (whose existence admittedly carries its own hazard).

> Non technical folks under-appreciate the cost and frequency of long-term technical debt.

Undoubtedly this is true, but there's an implication here in this context that somehow on shore, or more well paid developers don't create such technical debt, when in fact they do. It amazes me that I see team after team of competent well intentioned developers create one ball of mud after another. It's striking really.

> It amazes me that I see team after team of competent well intentioned developers create one ball of mud after another. It's striking really.

It is! But I don't understand... how? How does that happen? You should put good people together and get something good. But it is not always so. Very puzzling to me.

Oh, look, the answer is easy. Manage these projects with SAFE. SAFE is a corporate friendly Agile methodology that essentially says, "Fuck that agile stuff. Use the Agile vernacular to keep being as unproductive as you always were."

This is like heroin to these corporations. They use Jira and Rally to create a cult of numerology games that reduce tasks to filling time-boxed, random things- to-do. Be sure the Agile coach is drilled in the game and clueless about "technical-things". Add an equally clueless Product Owner whose background is Word and Excel and you'll create the best Big Ball 'O Mud anybody ever wished for.

And if you're running late, add a dozen or so new inexpensive -cough- "developers" from your favorite outsourcing firm.

I think software development misses a "doctrine". It is very hard to develop robust maintainable software while trying to chase the latest fad (edit: under constant pressure to deliver new functionality).

I have known this as a junior, never really getting to know a technology before hopping to the next one, and I am still having to deal with this now that I have a bit more experience, trying to convince my colleagues not to be so quick to dismiss the modern for the newer.

Sometimes I feel like I do not know what we are doing although being one of the senior members of the team. Stuff quickly snowballs into mud... It's like there is not enough effort or time to deliver functionality while also staving off entropy

I've heard non-technical folks with their heads in the clouds expecting to run millions of dollars in transactions through an IT system, but cringed at my suggestion that they're likely to dump more than a couple hundred grand one-time into the scheme. Yet the same person doesn't blink at paying significantly more than that yearly maintaining existing low-tech systems, and has already spent millions on ERP projects.

I think a lot of this effect is caused by wishful thinking from people embarking on business plans which they would realise are non-viable if they did the accounting properly. People are buying a fantasy instead of an IT system.

The difference is that an existing IT system is real and can be purchased for X amount. A potential future one cannot - and while devs are able to estimate (poorly) how long it will take others cannot and there is a real human bias - in fact one could say the future system is the fantasy

Purchases are good in the short term. You can evaluate them and pick the most suitable. Once you have settled with one product and know what you want it may make sense to work on optimizing your business with a custom fit solution.

Well, we all know why that is the case: uncertainty. If I pay $100k for a thing, I'm actually paying $100k for a chance at the thing by the date. Most likely, I'm going to end up paying 2x for the thing by 2x the time. Happens everywhere.

And that's not because the guy making it is shit. It's because while he's making it, the market is moving and I'm watching it, and when it moves enough I have to come over to him and tell him to change things.

That's why slow, costly things overrun by more and are later. It's because the world changes, and fast+cheap things are superior because even if they're worse, they exist and can therefore be changed to what the world is.

It's not just that non-technical people under-appreciate technical debt.

If you put in the time and pay the money to build an awesome system that is stable and usable for decades, there's only a small chance you'll be rewarded. First because no one notices when software is working. Second because you will probably have moved on to a different role at a different company after your wisdom is confirmed ten years later.

Saving money now is what gets attention.

That's literally the job of a CIO/CTO - manage technical capability of the company.

If you have a bad CIO/CTO - you're screwed long term.

Reply on news.ycombinator.com