How do you tackle expanding scope and accelerated deadlines?
Posted by MinimumArmadillo2394@reddit | ExperiencedDevs | View on Reddit | 33 comments
I just started at a new company in around March. They put me on a project where I'm the only back-end developer on the team. It's a typical microservice architecture except there are hundreds of microservices, not just a dozen like I have experience with, all managed by a group of maybe 20 people.
The original deadline for this project was supposed to be the end of May. The scope has expanded significantly and every single microservice has to be updated. There are processes to do this that make it a lot easier but they still take a lot of time and a lot of effort. I'm still learning how to do this because I've only done it for small things before.
I'm running into small issues like tests are failing in one microservice or the microservices. Just refuse to talk to each other locally preventing me from accelerating the timeline on my end.
Product has recently told us that they also want integrations with third-party services and they move the timeline up to be the beginning of May instead of the end of May. I'm not drowning in the work per se but I am struggling with the fact there's not that many hours in the day in order to do the work. I'm playing whack-a-mole with hundreds of different pieces in order to figure out where something goes wrong and anything in the chain has to be running locally in order for me to debug it.
I'm trying to figure out how to approach this from a product perspective and push back without saying or sounding like I'm not a good developer.
How have you pushed back against tightening deadlines or broadening scope? What do I do here?
sebasgarcep@reddit
Hundreds of microservices and 20 engs? I thought my workplace was nuts…
AcesAgainstKings@reddit
Maybe they're actually microservices...?
theDarkAngle@reddit
I mean I've been at places like that. Sometimes architects take the whole "Single Responsibility Principle" like, way too fucking far.
I consulted for a company that I really loved other than the absolute nightmare tech stack. I was amazed at their definition of microservices. They were I would say in the ballpark of about 2-5% of what I would consider a sane micro service. It was like nanoservices. They had one service for producing a particular kind of event, and one for consuming it, and the producer was really just a passthrough from an api gateway, and didn't do anything else, while the consumer was just a thin delegator to another service which had, effectively, one function (process the event and reply status/result).
That pattern was pretty pervasive, there were over 500 services that I had access to, I have no idea how many more. And it wasn't even like a good tech stack for it (almost entirely java). The cloud costs were enormous, the UX was slow, the DevX was atrocious, and velocity had ground to a halt long before I started.
There was constant cross-team negotiation on release scheduling because despite such a decoupled system, the services were still somehow highly dependent on the internal workings of other services. They shared key dependencies and resources (like one giant shared 20k table database schema being the worst one, each team had their own thin database but it had to have minute by minute consistency with the master one) and that database was owned by a whole other department. Same with the api gateway, that was its own team, same with the commons libraries (event shapes, DTO's, etc), same with the cloud config. It was the single biggest waste of time, money, effort, and talent I've ever seen.
MinimumArmadillo2394@reddit (OP)
Theyre working on consildating them into 14 or 15 of them, but the work is slow and only one person can reasonably do that at a time
Party-Lingonberry592@reddit
Ask them which features are less important so they can get moved to the low priority bucket. Fire your project manager. It's that person's job to make sure the work can get done and set expectations. to product and leadership. If they say "yes" all the time, you're going to drown in features and ship a sub-standard, barely working product.
"If these features are all high priority, we'll need to hire two more engineers to get it done on-time." That's usually when they step back and go "whoah... it's not that important..."
Ok_Influence8600@reddit
From what I've heard, there seems to be a problem with the organization itself...
In an organization like that, no matter how capable you are, there's a very high chance you'll be subjected to unreasonable demands, so I think you should consider changing jobs.
Basically, only things that are feasible are implemented.
If something impossible is attempted and a problem arises, who will take responsibility?
It's something I don't even want to think about, but there's a possibility that the responsibility will be pushed onto you.
Electronic_Candy3431@reddit
Hi! I’m his PO. I’m actively trying to get a better timeline and to get more engs on our team & within the company. The company is crazy. I’m making significantly less than I should be (and less than the girl who I’m training AND has less experience than me) so this is just a normal thing for them ☠️ Say a prayer for us
mechkbfan@reddit
https://github.com/FocusedObjective/FocusedObjective.Resources
Those resources maybe helpful to you. Give them a skim and see what's relevant for you
My comment that expands on it a little more
https://www.reddit.com/r/ExperiencedDevs/comments/1sywt2m/comment/oj1htfp/
engineered_academic@reddit
I would never share my Reddit account with people that I work with. Risky move!
Electronic_Candy3431@reddit
…..we’re friends outside of work ☠️ I knew about this post because he texted me it 😂
mechkbfan@reddit
Giving visibility / communication early as possible is the #1 thing to do, then letting the right people make the right decisions
ashultz@reddit
So its important to embrace that on the current course you will fail. That paradoxically frees you up a lot. Sounds like the company is a disaster and you'll get blamed then and it will really suck, so anything you can try now which will only sorta suck is actually better despite being unpleasant.
Figure out a realistic timeline and publish it. If you need the time stop working to do that design exercise with convincing documentation. If there are any parts that if they were dropped would help, call that out and see if they can be put into a later release or just axed. You can get a lot of milage with "you can have this full thing by June, but you can have this part which lets us prove out the concept while the rest of the work is done". And a plan that can be understood and followed is better than a guaranteed disaster even if it takes a long time.
And product doesn't get to just add stuff and move the deadline up, that's just make-believe and they're hoping you'll go along with it. They get to say what they want the most and that goes on top of your list, but they don't get to say how long it takes any more than you get to tell them how long it takes to do market research.
kbielefe@reddit
It's simple but not easy. Make a prioritized list of all tasks. Draw a line at what can be done by the early deadline and another line at what can be done by the original deadline. Have a conversation and come to a consensus about what goes in what bucket.
SansSariph@reddit
State facts, get emotion out of it as best you can
"No, we can't hit that date with the current committed work. It will take X weeks, given this costing I've prepared to meet the specified requirements. Is there something worth deferring to make room?"
"We have test reliability issues that cost me X days per month right now. Dedicated one week to reliability investments would pay for itself next month."
Estimating is hard but the keys are being comfortable saying no, and understanding the business won't invest in infrastructure or debt unless you bring numbers on what it's worthwhile.
lawrencek1992@reddit
Saying no is so important. Being a yes person to people please backfires in this industry.
Absolutely spot on about taking emotion out of it. I’m communicating facts about capacity and estimates (best guesses) based on those facts. I have no emotional attachment to how those facts are received, but I’m good at asking questions and proposing alternatives when people don’t like the reality of the facts I share.
lawrencek1992@reddit
It’s several things you need to do over the course of a project:
Raise delays early (e.g. struggles with microservices communication that wasn’t planned for) and explain how they impact release date.
Every time scope or requirements are added, say it will increase development time. Ask if product/stakeholders prefer to push back the release or do this as a fast follow. If the answer is neither ask what other requirements will be dropped in order to make the release date and keep this new requirement.
When you are given a project which won’t meet the desired release date, immediately flag this and provide a realistic release date.
Offer to identify which pieces of work can be done by the desired release date or identify ways you can speed up if they exist, e.g. by pulling someone on another team to help with implementation.
For huge things proactively propose versioning and what you suggest be included in version 1. Collaborate on this with product. Offer to provide estimates for each version after requirements for each version are defined.
Don’t bring emotion into it. Product isn’t the villain. You aren’t emotionally attached to requirements or estimates or deadlines. You provide time estimates and suggestions. Suggestions may be ignored, and estimates may be disliked. But don’t get upset about it. You are just sharing info.
If you deal with serious pushback, review project history. How long did things take and how long was your estimate. Use this to make sure your estimates are fairly accurate. If they already are, use this to as evidence you give accurate estimates when questioned about your estimates.
likeittight_@reddit
Evenings and weekends
bigorangemachine@reddit
Well my EoY review came up and I didn't get a pay raise so I quit
engineered_academic@reddit
Whoever reported this as off topic, this is actually the only real strategy that is guaranteed to work 100% of the time.
MinimumArmadillo2394@reddit (OP)
Probably reported it because its about EOY and not getting a raise, not at all about the post dealing with issues like expanding scope and timelines...
spez_eats_nazi_ass@reddit
Or just reported by a clanker bot shitting up things. They have been getting spicey lately. Reddit is toast. Like what kind of fucking moron has so little going on in their life “ima hit report!”
engineered_academic@reddit
You'd be surprised, tons of people report clanker bots as well. Reports are very useful on rule breaking content, this was not one of them.
bigorangemachine@reddit
well more I accommodated the scope... worked overtime (unpaid) and didn't get a raise... and I quit
The point is... get paid for it
diablo1128@reddit
You should constantly be thinking about you deadlines in relation to your work. When scope changes or you run in to unexpected issues you should be clarifying to management that the deadline may need to change and why. Make sure to have an updated timeframe you think is reasonable.
If management doesn't want to budge and demands everything be done by the original deadline, even when scope constantly increases, you just do the best you can working normal hours and whatever happens happens. Make sure to keep them updated on progress along the way along the way making it clear that meeting the deadline is in jeopardy.
Don't think if you work over time and get everything done that you will be rewarded. You met the deadline and got things done to expectation from managements perspective. They don't see you going above and beyond.
Management only learns when shit fails. So you have to let things fail. If they fire you for lack of performances or anything like that then it's just a shitty company to work for at the end of the day. You were never going to be successful unless you killed yourself by working overtime at the whim of management.
QuitTypical3210@reddit
Work overtime
engineered_academic@reddit
You need to find ways to manage upward. You sre getting dogpiled with unrealistic expectations, so its something where you need to say "yes but..." and either get more resources (with the constraint that it takes time to manage them) or you push out the timeline or features as scope increaes. The "fast/good/cheap, pick two" triangle.
Or you quit. :)
necheffa@reddit
The requested work exceeds the capacity of available engineering hours.
You are going to have to have a conversation about what is a must have vs a nice to have. That doesn't mean the nice to haves don't get done. It just means they are planned for a later release.
nasanu@reddit
Microservices? Quit.
MinimumArmadillo2394@reddit (OP)
Microservices is standard architecture...
Its ridiculous to quit. Literally just got here
Tired__Dev@reddit
It doesn’t mean it’s a good one. It was a trend built on scaling massive companies horizontally. You have a team of 20. At that point it’s better to create a branching strategy. The actual very thing you’re running into is the problem. There’s real upkeep and devops work that goes into maintaining microservices and often tooling needed to support them. What you’re actually indicating your post is common. Your services are more than likely tightly coupled
Tired__Dev@reddit
You got downvoted, and given today’s tech market you really can’t quit easily, but this is a 2022 quitting situation.
Tired__Dev@reddit
You might be being thrown into something above your ability.
I’ve made a career off of pushing back. The first thing you need to do is gather requirements from the initial scope you were given. You go through that, decompose how that would work with the current system, what you think is viable and not, and then offer a rough roadmap with loose estimates for each vertical slice (epic/objective, whatever you want to name it) based on your own ability and pad by 30 to 50% to accommodate new resources being on-boarded onto the team, or more junior developers. In that you list everything you need from what you currently see (stability in certain services, documentation, etc). Then you take what’s being expected of you now, add a new area with what that would need, and compare the two.
When you put it in terms of resources needed they start thinking about money. Once they start thinking about money they start prioritizing or providing you with those resources. If they can’t do this then they’re incompetent when it comes to their mandate; which more often than not is the case with business people because the only way to actually work in any area of tech is by understanding actual tech.
Physical-Compote4594@reddit
Hundreds of microservices and twenty engineers, and expanding scope and accelerated deadlines?
Start looking for another job right now. You picked a job at a company that is insane. You will not get any useful experience there, you will just get burned out.