Inexperienced non-developer wants to rewrite the whole app
Posted by k032@reddit | ExperiencedDevs | View on Reddit | 51 comments
I'm a fairly new developer on an unusual team. Its officially like a "forward deployed" engineer basically. But I work alongside customer and analyst directly and am tasked to just build them useful things and tooling directly/support their existing ones.
There is an existing app thats been made by one of these analysts using Svelte they all use. I'll tell you now it's not *great* but like it works. So I've kind of just been maintaining it, following the boy scout principal etc to just slowly build better standards and redesigns into it.
Another analyst comes along, who is on the military side. If you don't know they basically have their posts on a program like this then rotate as their commanded. He's a self taught developer and wants to rebuild this legacy app completely. Basically kind of hilariously told me to "cease work" on the existing one because he's got markdowns planning the new one.
Arrogant guy honestly, and it's a classic cautionary tale. The current app took years to get where it is from the last analyst and he's just gonna walk in with little experience and rebuild it all. Actually no, he said he wants to write "very little code and just plan" so I guess he wants to just make a "plan" and then hand it off to me and command me around.
My team lead kind of said "I don't care what that guy is doing we'll just keep doing us". But there is some potential internal politics and customer pull that this military guy can pull.
I'm starting to just build some of my own tools for new ideas and building into the existing app as analyst bring features. But wanted to get thoughts on this from other developers...because honestly I don't really work with many now.
I mean just let this dude fail? I've seen this before people just wanting a re-write to use "cool shit" and then it never happens. Do I try to intervene and "guide" him? Since ultimately I'm probably gonna be working on it.
SheriffRoscoe@reddit
They always do.
konaraddi@reddit
Never go full rewrite. Everybody knows you never go full rewrite.
johnwilkonsons@reddit
At the same time, I'm at a place that has an internal tool that still uses AngularJS. Like, the original one. We're not even using the latest version either, we're using one that went EOL in 2019 or so.
Refactoring that into modern Angular is effectively a rewrite no matter how you spin it, and the cost of making changes/adding features to this ancient artifact means we'll probably end up with a rewrite
And yes, they've been adding features to it since 2019, just never did any proper maintenance whatsoever (node versions, libraries, code is a huge mess of JS+Mongo so there's 0 types). It's our main customer support system so breaking it is not good, but sadly a common occurrence as there are 0 guard rails (types, linter, tests)
prumf@reddit
People don’t realize that’s it’s almost always impossible to map the entirety of a legacy app. You think you made a perfect copy just cleaner and then you get calls from random users saying it can’t do X and Y now, or that Z is broken.
Save yourself needless pain, don’t do a full rewrite.
MindCrusader@reddit
It depends. I joined the team where the Android app had almost a year of development and it was done by some "senior" that wouldn't be junior where I work. It was a duck taped solution, dev didn't even use git correctly. I decided to throw it into the bin and start over.
One year later - I caught up to iOS, because of the rewrite. It would not be possible without rewrite
rofolo_189@reddit
Yes, that's the smartest move here: Choose your battles wisely. This one seems not a battle you should fight. If he wants you to do stuff, go to your teamlead.
Leading_Yoghurt_5323@reddit
don’t fight it directly… just keep improving the current app and let results speak for themselves
NoConnection4298@reddit
They always do. Just let them do and give them ownership. If it fails, ensure it is known. If it succeeds, share the ownership (you should be able do that if you have higher seniority) and make sure they see the credit is shared. Thus, next time they don't do rewrites without thinking it through. This is how to fight with superstar developer complex.
NickW1343@reddit
Don't guide him or else you're going to be taking on quite a bit of his work. He's said it himself; he wants to code little and plan a lot. When those plans don't work out, he'll go to you if you're there to help. Let him do his thing, fail, and hopefully earn some humility and bounce back a better person.
chikamakaleyley@reddit
is this tool a utility / nice to have?
if so, could it not be built in parallel?
I don't see anything wrong with the idea... i don't like the potential of the bossing around, but maybe i misunderstand - you did say you're tasked with helping these folks build tools that they might need, right?
my thing is, if i'm the builder, they have the idea - i tell them how it can be done
military or not, one person here has a SWE title, a CS degree, right?
so i think - the analyst is in a position to say "I have this idea I want to build with ABC because XYZ"
You're the position to say "we can do that but FooBar is the constraint here, so it's going to have to be BCD and not ABC"
chikamakaleyley@reddit
top it off with "you are free to try it this way, but if i''m gonna build it this is how i do it"
Otherwise, let's say you commit to their plan and it contains some tech you aren't so good with, that can be an oppotunity for them to tell you how that works.
philip_laureano@reddit
Let him fail and stay clear of the blast radius
outlaw1148@reddit
Just let him fail and keep doing what you are doing. Im not sure how him wanting to rewrite the app impacts you, he is not your boss and your lead already basically told you the same
Organic_Bother9868@reddit
how do you handle potential internal politics in these situations?
NicolasDorier@reddit
You don't. You follow the lead for two reasons: First, he is the lead. Second he is right.
Enjoy the fact he can shield you from this.
snakebitin22@reddit
Absolutely correct. That is what people like me are here to do. I’m a chick btw, not like it’s relevant to the conversation or anything. Just sayin.
On top of all of that, you taking matters into your own hands is you doing pretty much the same thing as what you’re complaining about the other dude doing.
snakebitin22@reddit
Lead here. If your lead is saying not to worry about this dude, then don’t.
We deal with jokers like this all the time. It’s really more between someone like me and the scrum master to deal with than it is for you to worry about.
Just worry about your own work.
new2bay@reddit
I wish there was a way this could be the top comment, because it’s the best answer.
snakebitin22@reddit
Thanks!!
Calm-Bar-9644@reddit
I don’t have any advice, but I am curious how do you enjoy being a forward deploy engineer?
I’m currently interviewing for this role that is related to being a forward, deployed engineer, and would love to hear your perspective on.
My role requires about 10% travel to meet up with financial customers
k032@reddit (OP)
I enjoy it, I mean it could be different depending on the role and all. Coming from like building apps for broad general audiences to sell or on a contract in a big team of developers. To intimately working with customers and actual users. Feel less like a salesman for some software, more like part of a team doing something. It's given me more meaning I guess.
But that being said still bullshit like this and like competing heads wanting to kill projects to use other stuff. There's also working on client sites and lack of remote work or hybrid but not a big deal for me.
Calm-Bar-9644@reddit
Yeah, that makes sense. Do you still get to work on standard web development skills pretty thoroughly, or is it a lot more service level type of work?
For my role, it’s still involves what development type of work. But it still sounds like more along the lines of using their platform and then building small features to extend it out as needed, rather than building larger features on the front end or the back end.
k032@reddit (OP)
Mostly web development work but also kind of service work. This role has been more just building our own solutions for the most part. It's basically contractor so no selling a product. Maybe leveraging shared tooling etc.
But I did in the past work at a company doing basically the same role in a similar manner, using their product and building on it for a specific customers needs.
Had it's pros and cons I guess but.
ninetofivedev@reddit
So there is a couple of things.
There is a chance they’re in over their head, this will fall. Thank you, next.
But also just because the old app took over a year to develop doesn’t mean you should dismiss that it can’t be rewritten quicker and better.
This is literal iterative design and we stand on the shoulders of giants.
Your concerns are valid but your criticisms seem a little biased based off the sentiment you hold toward this person.
gUI5zWtktIgPMdATXPAM@reddit
I missed that part too, wtf. He makes a flashy plan and hands the implementation over to the scape goat. 😂
gUI5zWtktIgPMdATXPAM@reddit
It's pure underestimation of the work involved. Every old code base has quirks and most of them have very good reasons for existing. It's the unknown unknowns, the things you don't know.
Rewriting it all fresh means he'll hit many of these things, some of them are extra annoying as it's some business process that only occurs once a year but it's super critical.
He'll most likely flop.
You really need buy in from all the stakeholders and fellow developers to rewrite something as it's a bumpy road and a plan on how to migrate. To get this buy in he needs real motivating reasons he can convince people to join him on this journey and that the pain is worth the rewards.
Ultimately it may be easier to improve the existing application and strategically refactor it. It's a longer process but requires less radical buy in.
Altruistic-Bat-9070@reddit
I would put in writing that you have been slowly rewriting this app when adding new features as it made sense to do this from a problem statement perspective and esch time you solve a problem the app improves. Put in writing this is how you will continue to improve the app and you will not be doing any overhauling.
Then let him fail. Sounds like he designing for the sake of designing and hasnt figured out you need problem statements and stakeholder buy in to get something done. Not just fake authority.
Altruistic-Bat-9070@reddit
To the military guy, just has to be in writing on a work comms system to score it was communicated
rodw@reddit
Who are you suggesting is the audience for these written statements?
Put it in writing and then what? Send to the lead? Send to Pvt. React? Post it in whatever kind of roadmap/planning/design forum is appropriate?
tdifen@reddit
Just approach it positively.
First you need to get him to figure out the priority of this. Show him all the work you have going on and get him to tell you exactly why he feels this is more important. This shuts people up 90% of the time.
If he keeps pushing the next thing is just let him go write out all the specs. Best case he actually puts something else that's better than what you have (unlikely). Next best case he learns his lesson to not tread on developers.
There's a reason most senior staff respect their developers, it's because they were once young and naive and tried to take on a complex staff and failed miserably and then decided to just listen instead. Some people are smart enough to learn that lesson from other peoples mistakes, some people are so arrogant that they think they're special and fail spectacularly.
reddit-ate-my-face@reddit
Let him rewrite it while you continue what you're doing.
It will go next to nowhere or fail miserably like most great rewrites in the sky and you can just chuckle and keep on keeping on.
F1B3R0PT1C@reddit
He’s likely to write a markdown file, stuff it into Claude and expect a working result come out. Just wait until he hands you a half-working copy and then tell him to take it up with the bosses
beaker_dude@reddit
He probably got the markdown file from Claude in the first place
mpanase@reddit
I'm always happy to let those guys fail.
Problem is... are YOU his audience?
Wouldn't be the first time a charlatan makes a "grand plan" that's actually stupid, but he is great at selling it to the person who grants approvals. And suddently the moron has a team of 10 people working for him, including you. And if the "grand plan" fails, we need to decide why it failed... at it for sure was not because a shit plan was created and approved.
Don't fight him. Ignore him.
But, if you can, make sure that whoever needs to approve ti to become bigger knows it's shit BEFORE getting the sales pitch for it.
crustyeng@reddit
Let things fall as they may
JohnWangDoe@reddit
pltr?
kayakyakr@reddit
He's just gonna vibe code a replacement in react. It might work if the app is small enough and he makes few enough architectural changes.
But to you use react internally? You said the app was svelte currently (week) and that svelte was used company-wide. That is your big reason to push back. There's something to be said for keeping the same framework across your stack
Snoo_47613@reddit
In the past, I would have said: just do your job, you’re doing great, keep everything documented so you have evidence of your advice, and let him fail.
However, nowadays building an app is much faster. I’d see this as an opportunity to build something new using modern patterns, technologies, and approaches. But you need to clearly communicate the risks and time estimates. The business needs to understand what they’re investing in and what they will get in return.
This is the most important question you need him to clarify: is the business willing to invest X months just to rebuild it? Will that rebuild generate more income? Is it worth it?
WJMazepas@reddit
Is the military guy your actual team lead?
If no, then dont worry about him. Just focus on your tasks defined by your lead and your team
robhaswell@reddit
Just calmly state your concerns to your superior and then drop it, which is sounds like you have already done, so just carry on.
Just as a side note 'he said he wants to write "very little code and just plan" ' sounds a lot more like they are going to hand it off to AI.
yellow_smurf10@reddit
Was the guy a 2nd lt ? Lol
I swear every 2nd Lt I have worked with were giant arrogant assholes
Hziak@reddit
If he’s just gonna get rotated out eventually, consider yourself lucky and just keep doing you. For most of us, that guy gets hired permanently into a VP or CTO type role where everything they say is gospel… this guy sounds like the same breed of tool, but not in a position to tangibly do any real harm as long as he can’t run away on social credit to your bosses.
Some polite but firm emails from basically anyone informing him that there isn’t budget, resource or demand for a ground-up rebuild this quarter should be enough to make clear to him that he shouldn’t go around trying to poison the well against anyone who opposes him because the direction to not follow his idea comes from business justification, not individual pettiness…
rwilcox@reddit
Yup: since they’ll be rotated out: smile, nod, don’t be as transparent as you might normally be, let them write tons of specs, delay, then file them appropriately (the round file).
anarres_shevek@reddit
Red Flag! Red Flag!
serious-catzor@reddit
Here is my take on things like this.
Phase 1: Opposition
This is the part were we argue and discuss and try to do everything we can to prevent the wrong thing from happening.
Step 2: Surrender
We lost. Time to reconcile and apply ourselves to understanding what is going to happen and how.
Step 3: Join them
It is happening so our focus should be on making sure their solution is as perfect as we can. We no longer discuss/argue to stop it. We discuss/argue how to do it better instead.
What I see and hear is people just stay in Phase 1 forever. People will stop providing their opinion, advice, help and support. Don't be that person. Instead always apply yourself towards what is the best outcome that is POSSIBLE for the project/company. Don't stop just because the best solution is off the table.
Be professional. Be the adult.
(You can also do both. While working to put the best solution back on the table, also work to improve the one on the table)
CherryChokePart@reddit
Not your problem.
beaker_dude@reddit
FDD - Fashion Driven Development. “We don’t do thing because they are easy, we do them because we read a blog post about it.” - JFK (probably).
Boy Scout this one.
drnullpointer@reddit
> I'm a fairly new developer on an unusual team.
Here is the issue: you are new guy it means there are other people with more tenure.
Let them sort it out.
You have no idea what really is happening behind the scenes and you might just become a torn in the side for a wrong guy.
If your manager is either too stupid or too powerless to stop this, then why do you think you, a new guy, can do more?
No-Economics-8239@reddit
If your lead doesn't care, why should you? What political juice do you have to influence outcomes, and is it worth it to use it here? What options do you have? Go over your lead and try to get someone higher in the hierarchy to care? Even if that is successful, it could generate some resentment.
This sounds like low stakes hubris. Worst case, he crashes and burns and takes the application with him. Note your concerns and move on.
jamesg-net@reddit
I think you have a responsibility to state to your employer (or the management chain) why you think it's a bad idea in a factual and respectful way. If your employer doesn't choose to listen to you, keep following their guidance and let it be. You can't win every battle, and you'll ruin your relationships for the ones you can win if you try to.
stashix@reddit
I had an ex-military PM on a project, she was pretty horrible.
Basically just yelling and demanding stuff without having any clue about the actual work.
Like come on lady this isn't boot camp, I'm not some grunt you can boss around just because you both signed up to kill brown people for no reason.