4 ms·

The biggest trap is new and shiny. Let me explain, they decided in the company to do a complet rewrite while we only needed a few apis connecting to the existin

The biggest trap is new and shiny. Let me explain, they decided in the company to do a complet rewrite while we only needed a few apis connecting to the existing software. Its a group of 8 people. The current software is written in PhP, jQuery, Mysql and some use of Yii. Blazing fast, customers are happy. New guys come and of course we need a rewrite. Everything has to be microservices. Now they have to work in Kubernets, Docker, React, Node, elastic search, MongoDb. With each of these is nothing wrong, but its a lot of new technology to pickup with 8 people. Now the clients hear when they want a change or modification, no just wait till we have platform 2.0. Long story short, development has gone downhill, customers unhappy and after 6 months they are already 12 months behind schedule. This company will byte the dust within a year.

phendrenad2 7y ago
A very common story. Engineering managers need to be aware that their engineers will cry for a rewrite and say there's too much "technical debt", but it could easily destroy the company if you let them go hog wild with the rewrite. You need to quantify the benefits up front and make the engineering team meet the milestones, none of this "yeah we're polishing the codebase because reasons"
Ididntdothis 7y ago
A lot of rewrites end up trading one set of problems with similarly sized set of different problems. But to be honest the rewrite was probably a positive for the devs. They have more cool stuff on their resume and will do better in the market. That’s one of the big problems with finding jobs. If you do what’s good for the company you may quickly end up with an outdated resume and be marked as dinosaur who hasn’t been keeping up. Even your own company will hire new people for new sexy projects instead of the people who did what was good for business.

phendrenad2 7y ago

A very common story. Engineering managers need to be aware that their engineers will cry for a rewrite and say there's too much "technical debt", but it could easily destroy the company if you let them go hog wild with the rewrite. You need to quantify the benefits up front and make the engineering team meet the milestones, none of this "yeah we're polishing the codebase because reasons"

Ididntdothis 7y ago

A lot of rewrites end up trading one set of problems with similarly sized set of different problems. But to be honest the rewrite was probably a positive for the devs. They have more cool stuff on their resume and will do better in the market. That’s one of the big problems with finding jobs. If you do what’s good for the company you may quickly end up with an outdated resume and be marked as dinosaur who hasn’t been keeping up. Even your own company will hire new people for new sexy projects instead of the people who did what was good for business.