[trombone5000]

What's wrong with fad and hype driven development? It may be better to replace software regularly than to find yourself or your organization dependent on something ossified in place.

In the long run it might be better to treat software as "fast fashion" rather than something meant to last forever.

[onion2k]

What's wrong with fad and hype driven development?

Ostensibly nothing, so long as you can tell when things are better. If you're trying new things and taking on new, better ideas quickly then you'll improve rapidly. If you're also "failing fast" and throwing out new things when they don't work then you'll improve even more rapidly.

If you're abandoning good tech simply because it's old, and not fully understanding the drawbacks of the new things you're switching too, then you're building an empire of tech debt that all your good team members will eventually get sick of fire fighting and they'll leave.

Novelty doesn't make people loyal. Working on strong tech that people are proud of does. Sometimes that requires a deep dive into some tech over a number of years.

[AnimalMuppet]

> What's wrong with fad and hype driven development?

The "flavor of the month" band wasn't as good as The Rolling Stones. That's not the end of the world if all you did was buy their CD, and then never listen to it again after the month was up. If you completely rebuilt your stereo to try to make that CD sound better, though, that gets more expensive. (Especially if you rebuild it again next month for a different band.)

Development is more like rebuilding the stereo than buying the CD. It's expensive. It takes time and money that could be spent on other things.

Worse, in replacing dependencies, you may replace a dependency on something that works with a dependency that doesn't work nearly as well. You may replace your Corvette with a Corvair. (And spend time and money to do it.)

If you have battle-proven tech, there is a place for eventually replacing it. Eventually, though. Not very quickly. And when you do replace it, don't replace it with the fad of the month (or even the fad of the year).

[pjmlp]

https://blog.codinghorror.com/the-magpie-developer/

That is what is wrong.

[trombone5000]

From the link:

> Pete concentrated on building a system [in COBOL] that works for him and his clients.

If that system isn't replaced before Pete retires, it turns into a significant hidden risk.

You don't know how dependent on something you are until you try to replace it with something else. If hype is driving the replacement, so be it. An organization can make replacement a regular practice and get good at it; or it can find out when it unexpectedly becomes necessary.

[pjmlp]

Pete could have discovered that even COBOL follows hype, no need to switch stacks.

https://www.microfocus.com/en-us/products/visual-cobol/featu...