There there. Rewriting from scratch never go smooth. You at least have 3 years I'd say.
this post was submitted on 20 Jun 2023
72 points (98.6% liked)
Experienced Devs
3916 readers
2 users here now
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
founded 1 year ago
MODERATORS
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.
That screams inexperience in their end, to me. 20 years in the field, I learned to respect legacy. Can't move away from it without getting it under control first and then weeding out the smelly parts.
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.
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.
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.
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.
Should probably start looking yesterday.
Exactly this - it's actually fortunate, because you can clearly see it coming, so you've got plenty of time to job hunt. When you find something, don't feel bad at all about bailing on the current one.
True. I'm in europe as well, so they can't just fire us all without a lot of paperwork and planning. So even if it happens I'd know for a while.
Although next time I'll not work for a company with a mainframe. I think this is going to be my new question to as in interviews, "do you have a mainframe?"
i wish i could bookmark comments on kbin :/ now i ll keep screenshoting meanwhile
Can you not use a traditional browser bookmark?
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.
The company is fucked, you are not. Apply for new jobs elesewhere, pronto.
It depends on how confident you are in what they are working on. If your guess is correct then I would probably start looking.
If I were you, I would be worried.
Not so much about getting laid off because you're not part of the new CTO's "in group". I would be worried because your company is investing a lot of money and time and executive attention into an IT project that has a very high chance of failing.
Hiring a new CTO from a startup is perfectly reasonable. Having that CTO bring along a lot of experienced developers can potentially be a good thing, especially if you are having trouble hiring people with the right skill set. But if that group is going off on their own and trying to do major innovation without taking significant steps to work with the existing company staff to understand the problems that they have faced and the current environment they are saddled with, then that group is very likely to fail.
view more: next ›