There there. Rewriting from scratch never go smooth. You at least have 3 years I'd say.
Experienced Devs
A community for discussion amongst professional software developers.
Posts should be relevant to those well into their careers.
For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:
- Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient
Yeah. Everything depends on the complexity of the product, but it's just as likely that it's the new CTO and his team that gets canned when they get bogged down in the details and the costs start racking up.
Startups inside companies usually get shut down once the bill gets too high. I've experienced this first hand
This may be the case. They've gone from "this should be easy" to "oh, we never thought about that" pretty quickly.
Uft, story of my life
The biggest problem with that approach is your team loses their roadmap, funding for new initiatives, and ambition while that's happening. Your sprint backlog has nothing but minor tech deficit tickets in it, and overall it becomes a chore to get anything done.
Counter point. Sounds like a c-level pet project on steroids. It doesn't sound like anyone is planning a migration. So they are relying on a big bang.
Now... A question for the panel: how would you say big bangs on corporate software projects with actual customers typically go?
How do they typically go? They don’t ;)
If OP play their cards right they have a wonderful legacy support gig for life
COBAL is still a thing
VIVA COBAL!
This is true, but it isn't good for OPs long term prospects either. Dumping a pile of money in a hole while taking on legal risk means that the losses are going to need to be made up somewhere.
Big companies going startup rarely goes well. If they're doing what you think, then it's already on a path to failure as they're doing their work in isolation without input from the people who know the current system well, or the many legacy intricacies that need to be addressed.
Migrating from an old backend to a new backend written by people who don't know how the old backend works sounds like a recipe for disaster. They will also be under pressure to deliver whatever it is they're making in a way a startup is not - so expect a cluster fuck of chaos as a rushed migration to a half written replacement is forced through.
If you don't trust your new CTO and he's not sharing a vision for the future but instead seems to be building a new private kingdom, then ask yourself is that the kind of place you want to work. You're a dev working in a company where the CTO doesn't respect your or your team enough to keep you updated. Maybe it's time to be thinking about moving on if you can't get any concrete assurances. That doesn't have to be immediate but maybe time limit how long you will work for the company and have an exit plan ready to go early.
I was hired onto a project like this. Had to sign an NDA and we were completely separate from the rest of the company, slack email etc. People weren't allowed to interact with us unless they signed the NDA also, most of the company didn't even know we existed.
We were actually architecting an alternative to something a third party was providing internally, and had to be super secret cause of the contract.
So I guess it depends how much you like your job. The market sucks right now and there's no guarantee you won't leave and be laid off from your new job elsewhere. I would stick around cause it's less effort til I find out what the deal is. It's not like they are gonna be able to cut over the entire backend suddenly if that's what they are doing. But be saving money in the meantime.
I agree with @pizza_rolls, unless you can find out more about exactly what the startup-group is working on, I would base my decision on how much I'm enjoying my day-to-day work, how good my co-workers are, and how good the opportunities are for me to learn/grow my skills.
It isn't usually a good sign when a new higher-up is bringing over large groups of people from a previous place, but it's not always bad (or nefarious). It also depends on the scale of things. A close-knit 10 person team who has been working with each other for years can be an incredible asset when brought into a larger company that can provide them more resources. And giving them the space to continue doing their thing can lead to awesome results. This is usually the case when they are building something the compliments the offerings of the larger company, rather than trying to rewrite or replace some core offering of the larger company.
If you do find out for a fact that they are rewriting core backend services without working with the existing teams who know/understand these systems, then that is a huge red flag.
CTO coming in hot, an employee poaching lawsuit, pet dev team working in a "bunker" separate from corporate, and that no matter how well-documented and designed "Chesterton's fence" applies to back-ends so it's unlikely to be a smooth cut-over. These are all bad signs.
What's good is that you have some number of months, maybe a year, maybe more, to find your next role.
Assuming that your company has a profitable business, and you are working on the part brings in the revenue that pays the bills, you'll keep that as long as your company is interested in keeping that business. Your CTO is burning money (and fast!), maybe they've picked that habit up in a zero-interest environment, but well interest rates aren't zero anymore, so I'd be more worried if I were part of the secret internal startup.
It depends on how confident you are in what they are working on. If your guess is correct then I would probably start looking.
What the company is doing doesn't matter as much as of you are happy and growing in your role. Keep your resume updated. Interview at least 1 time every six months. Do you work, do a good job, do it at a sustainable pace. Leave when these things are no longer true.