[gaius]

Missing the biggest red flag of all, engineers wanting to just play with new toys and pad their CVs. Ask the engineers why they want to rebuild and listen carefully to the answer and if it’s vague handwaving and buzzwords (microservices! Containers! New JS framework!) and no hard numbers to justify it, just say no.

For example “we spend X/year on AWS but if we spend Y to rewrite in C++ we need fewer VMs and can cut that to Z/year” is simple calculations. If your engineers can’t even do that, their motives are suspect.

[ebiester]

On the other hand, “we cannot hire anyone to work in COBOL/Perl 5.8/Tcl/other outdated language” is a very real problem. It turns out that 2018, developers are judged for working too long in old technologies even when we know as in industry that a developer can learn a new language.

[gaius]

I wonder if that’s really true. I bet loads of people would be delighted for the chance to go on using their old favourites.

[wffurr]

It's absolutely true. People with enough experience to have "old favorites" tend to be very senior and expensive or retired.

New grads and junior engineers can end up trapped in a career dead end if their first job is on seriously old legacy tech.

https://medium.com/@csixty4/pick-was-post-relational-before-...

I almost fell in the same trap, but quit a similar job to go back to grad school and get my Master's in CS.

[shoo]

http://boringtechnology.club

[adrianN]

The problem is that Y and Z are just numbers you make up. Reliably estimating them is impossible without at least building a prototype.

[gaius]

Sure, but prototypes cost orders of magnitude less than Y. And your engineers can scratch their new toy itch at zero risk.

[adrianN]

In my experience getting any funding at all is about as hard as getting the whole project approved.