Scene: Surprise meeting with the project owner 0-3 days before the go-live date
“Hey team, the business and I have decided to postpone the project release by n=1-3 months because [they aren’t ready for it / it isn’t finished /regulatory reasons]. And since we have some extra time now, we can tie up all the loose ends on this project (i.e., ‘we’ve added n+1 months worth of backlog items to the MVP’).”
I’m still a greenish dev, so maybe this is normal, but I’ve had the same story going on for over a year now, and it’s really starting to burn me out. In the beginning, I was optimistic. Now I just hope for the project to fail, or me to get off somehow, but this thing just won’t die.
Anyone with experience on similar projects able to share words of advice? Do they ever end up working out? Seems there’s a death spiral, since we are always rushing to a deadline, forgoing tests and quality but never cleaning up our mess because we’re already behind. Yet I somehow feel like I’m the crazy one for thinking this 6-month “quick” side project turned 2+ year half-rewrite will have trouble meeting it’s Nth deadline.
You must log in or # to comment.
It’s very common. I’d bet most software projects still fail. I once met a guy who’d been a gamedev for over 10 years at some big companies, and every game he ever worked on got cancelled.
Sometimes these long, poorly managed projects do succeed though. Usually because they launch a beta or get publicly scheduled for release, and the sudden reality check causes someone senior to trim the scope down dramatically.
It might be worth sticking around if you think you’re learning things, but impose some personal limits. Don’t kill yourself trying to meet some idiot’s impossible schedule. Work your contracted hours and no more. Be blunt and unashamed about how long tasks really take. Share your concerns when the month’s schedule looks unrealistic, referring back to previous tasks that overran. This is how you learn to one day become a lead who doesn’t run shitty projects like the one you’re on.
I admit it’s possible the project “succeeds” and gets out the door. My prediction in that case is that we limp along and eventually give up after maintaining it for a while.
I only work my ~40 hours a week. When I did much more than that, I think my output went negative.
I think I learn a lot, at least. The project has a more “modern” stack than the company’s other main product. And management/leadership being hands-off means I make a lot of big decisions myself. Many bad decisions, but at least I learn what not to do next time.
If you see a real chance of it shipping soon, that might be good experience. As I mentioned, a surprising number of grizzled senior devs have never actually shipped anything.
But if you see better opportunities elsewhere then just go. Sad reality is that job hopping early is what gets most people a good salary. Very few companies give real raises. The only time you have bargaining power is when you haven’t joined yet or when you’ve already made plans to leave.
Sadly not. This post comes after my frustration of this same exact meeting, and now the project is delayed by a nebulous 2-4 (or more?) months. Sounds like I may actually be moving off of it temporarily since it’s been pushed so far back, to another, slightly less ambitious project that’s getting started. To be determined if I can help this next project go much better.
A big fear I had was that a failed project would reflect poorly on me looking for jobs. But hearing how common dead projects are, I guess it’s no surprise that many people go so long not seeing a successful one.
First thing I explain to new hires is to never fall in love with your code at work.
It’s a means to an end. You can absolutely love code, but never ever your work code. Because at the end of the day, you are expendable.
Look for another job.
Companies like that are very unlikely to change their view that engineering’s quality and sustainability practices are a perpetual waste of money.
That, and product doesn’t know what they’re doing, and they’re okay with making engineering also suffer for it.
Nor do they care in practice about the engineers getting burned out.
After you leave, when you glance back at the company at any time for the next 5+ years, you will see that they have learned pretty much nothing.
I’ve been burned out once, and I’ll never let it happen to me again, or anyone I work with. It’s like depression; it’s an indescribable experience.
Here’s one self-test to measure how burned out you are: https://www.peoplestorming.com/burnout-assessment.
High on all fronts on that test, which does not surprise me. Though what you describe sounds worse than what I have. I’m just generally tired and pissed off, despite thinking myself a normally happy guy.
I’ll take this as my nudge to put my casual job search into overdrive.
This sounds like the old waterfall approach to development.
Design the whole system, create the whole system, test the whole system.
The problem with this approach is that requirements almost always change or scope creeps in those timeframes.
Now most companies are bad at agile. But even moving slightly towards it is better than nothing.
This will continue to happen until the project management changes unfortunately.
If the system can’t be worked on in small independent chunks this is basically guaranteed to happen.
We do agile very loosely. But we have a two week sprint and at the end we, hopefully, have the features we decided on done and deployed. Then we can get feedback and add the required changes to the backlog for a future sprint.
This way you get feedback a lot quicker and as you pick work every two weeks you can keep things moving forward.
Chances are the company won’t change so if it bothers you looking for another job may be a good shout.
I don’t have experience with that in particular. I’ll share my more general, tangential thoughts.
MVP is minimal. Extending the scope like that makes me very skeptical (towards scoping and the processes).
Everything you are concerned with would be important topics for retrospectives, or even meetings with management. But of course those don’t exist or are open in all environments. In my team I could openly raise such concerns.
If you’re always rushing to a deadline, or feel like that, think of what you can do and influence to improve that. Retrospectives? Team disuscussions? Partly tuning out of management given focus and doing what you deem important and right? Look for a different team or employer?
It turns from Minimal Viable Product into Maximum Valuable Product!
Or Modified Viable/Valuable Product
@yournameplease These things are, unfortunately, pretty common.
OP admitted they were pretty green though, so they’ll learn with time what makes a good employer for their work style.
Honestly, I’d say stick with it for a bit just to have the experience. Then move on to a different company, which will be a different experience. If it’s better, they’ll appreciate their new job; if it’s worse, they’ll know that their first job wasn’t as bad as they thought.
In my experience this does happen on occasion, it absolutely shouldn’t be happening all the time though.
Generally when this starts to happen my team lead puts his foot down and says, no more changes until you sign off on what we have and we’ve released the MVP. After all, if the core functionality is done, then the MVP is done and we don’t need to keep sitting on it.
Generally when this starts to happen my team lead puts his foot down and says, no more changes until you sign off on what we have and we’ve released the MVP.
I had a situation like this where I shut down production because a project manager didn’t understand MVP and kept trying to grow the requirements with every meeting, and getting more and more agitated and even bothering my staff.
He forced me into multiple meetings with my boss and HR to hear “both sides”. By the end of it, he relented, the project finally shipped, and then they fired him.
It sucks that he was fired, but I don’t understand how anyone is confused by the term MVP.
That’s the agile mentality, where PO are pressuring you to deliver on your Sprint goals. In my opinion working on Scrums really burns down people
Just take on fewer points per sprint, if you can’t make it every time? Scrum is about becoming predictable, not being the absolute fastest. That’s been my experience, anyway. If your PO is pressuring you to take on more, you say “no”, because that’s your responsibility, not his.
But maybe that’s just me.
Yeah wtf is happening here where the data shows you have a story point average and you boss is like, can we go higher?
Like no?
We are reasonably consistent with estimates, but there’s this hidden assumption that 1 point equals 1 developer day. So even though we consistently get 20-25 points done per sprint, we typically cram more items to meet that 30 point threshold.
Oh, and of course you may end up dragging items sprint to sprint if they don’t get finished.
In my opinion working on Scrums really burns down people
Maybe im old but the old way was worse.
Building a project for a year without any feedback then suddenly having to pivot burns people even more.
My project fits both. It took about a year before this was shown to more than a couple business users. But we still had Scrum sprints and pressure to get items done at the sprint, even with no deployment or demo for feedback.
It’s said that 80%-95% of software projects fail.
Of course, that was before we slapped the word “AGILE” on our planning document and kept doing the importany things exactly the same way.
So now the success rate is much better.™
Narrator: It was not.
What people miss is that the actual realized rate of project failure, in an average software team, is much worse than 95%.
A typical team isn’t releasing 1/20 successes. They’re doing much worse than that. (Edit: As GoodEye8 points out - most of this is due to how these teams are mismanaged. The same developers thrive in better run teams.)
Well structured teams with healthy habits consistently deliver dramatically better results.
So it’s eye-opening to realize that the 5% of projects that succeed are, on average, being delivered by the exact same 5% of software teams, over and over again.
The reason this matters to you is: you should change teams. The next project very probably won’t be better, in that team.
My experience has been that it’s often not the team that’s the problem, it’s the management. I’ve seen a team full of talented developers who know how to successfully launch, only to barely get anything done because management keeps reprioritizing everything. It seems in OPs case the org itself might be the issue. Even if they move to a team where the PO actually does their job instead of letting the MVP balloon the team keeps fighting business just to deliver something.
If I was OP I’d probably look for a job in a different company.
My experience has been that it’s often not the team that’s the problem, it’s the management.
Absolutely. Most developers are fine. It’s the management style of the organization that causes the continuous stream of project failures.
so maybe this is normal, but I’ve had the same story going on for over a year now, and it’s really starting to burn me out.
Get used, it’s normal in some cases - projects that are most likely failing and will never deliver anything productive.
Think about this way, that . While they’re postponing you’re making a couple of improvements you’re getting payed for something that is now very in your comfort zone and you’ve to do a little to no effort to deliver some progress.
This is a management issue, may have come from poor requirements, high expectations, ineptitude in software dev. project management or all of the above combined.
Your best course of action is to realize that it’s not worth for you to burn yourself trying to deliver more than expected or jump ship. Just do whatever you’ve to do at the pace you feel comfortable, wait for the project to fail and move on. Jumping ship won’t help you much, it will essentially degrade your professional image and force you to learn an entire new architecture of another project that may end up just like that one. :)
Yes, considering it as a paid education always helps. I don’t really think of anyone here as a mentor, so I usually have to study on my own to learn what I need, and I still tend to regret most design decisions I make. And there’s just that looming feeling that everything I’ve worked on is ultimately worthless. But I guess all of this is just part of the software development job, ha.
Interesting that you say jumping damages the personal image, since it seems what most others here advocate. This job gives me good perspective, so I still wouldn’t want to go elsewhere without convincing myself that it’s a meaningful improvement.
And there’s just that looming feeling that everything I’ve worked on is ultimately worthless
As long as you’re learning and getting payed it is worth it… in some cases it even goes further to “as long as it pays good”.
Interesting that you say jumping damages the personal image, since it seems what most others here advocate
Let me explain why, from the perspective of a developer who eventually transitioned into management: Occasionally, even seemingly futile projects yield results, and the company manages to ship something, albeit subpar. If you decide to abandon ship before the project’s completion, you risk being branded as unreliable and weak minded.
Projects that linger are often sustained by middle management’s relentless promotion of a particular narrative or by their skillful manipulation of senior management (bullshitting). This persistent advocacy creates a perception of the project being incredibly challenging, yet the “highly competent” middle manager successfully sees it through.
Once the project triumphs, any prior skepticism dissipates, but the narrative of its formidable nature remains, and the middle manager continues to champion their foresight, claiming, “As we can see now, I was right about this project. It was nearly impossible, but our exceptional team delivered, and here we are.” All parties involved receive rewards, while those who departed before the launch are often perceived as weak by their peers.
The job market is small, and having a reputation for bailing when things get hard is bad. What we witness in software development mirrors broader societal dynamics—in the past, survival hinged on confronting danger and often dying, whereas today, it’s more akin to a waiting game to see who commits suicide first. Exiting such projects is akin to playing “Russian roulette” with your IT career because regardless of the project’s outcome, remaining loyal to the company and sticking with the project is typically a safer bet.
Side note: Occasionally, a middle manager may push everyone into quitting, thereby shifting the blame for the project’s failure onto the workforce and paving the way for securing additional resources or personnel to then covertly overhaul the project and deliver something.
Thanks for the response. I agree that the project’s big boss has an impressive ability to BS on the greatness of our project, and it may be enough to push the project past the finish line.
It seems you put a lot of weight on the project’s “triumph.” If the project fizzles out or fails spectacularly, does that not make you more of “the fool who couldn’t do it and didn’t know when to quit?” I don’t think I’d hold it against my coworkers for leaving if they think it would improve their situation. (And doesn’t a sound project plan account for the fact that you may lose people every so often?)
Interesting note about small job market though. I only have a ~20 person IT department without much churn so it feels quite small to me still. How do you see this reputation spreading? Just the diaspora of former coworkers is wide enough that most/many companies tend to have someone who knows / has heard of you?
If the project fizzles out or fails spectacularly, does that not make you more of “the fool who couldn’t do it and didn’t know when to quit?”
I see your point however you’ll be covered by the dynamics of the organizational hierarchy. When the mid manager’s ability to bullshit senior management eventually runs out then the project will fail, not because of technical reasons, but because the senior management will terminate it. The mid manager will then get reassigned to somewhere very far away and you’ll get a new project with a different manager.
In teams with three+ developers, the one who often bears the brunt of failure is the middle manager, not the workforce. Senior management typically holds the middle manager accountable for the project’s shortcomings, rather than the individual contributors. As long as you fulfill your duties (do whatever is asked), your reputation will remain intact, portraying you as someone who consistently delivers without giving up.
At the end of the day it boils down to the waiting game: who will quit first or run out of bullshit. This is the dynamic within most organizations and ultimately, individuals who “do whatever is told” and never quit tend to emerge as unscathed heroes.
How do you see this reputation spreading? Just the diaspora of former coworkers is wide enough that most/many companies tend to have someone who knows / has heard of you?
A guy knows a guy that know a guy… reputation plays a significant role and even seemingly innocuous comments “yes he was at my company for 1 year and he seemed like a nice guy but then he left before delivering his first project” can have far-reaching consequences.
Moreover, burning bridges by leaving a company before delivering a project can indeed makes it next to impossible to return in the future. Maintaining a good relationship with former employers is crucial, after all you never know when you may need to go back to some company.
I only have a ~20 person IT department without much churn so it feels quite small to me still.
In a smaller or medium-sized city where good IT job opportunities are limited, burning bridges will significantly impact your future prospects. Each negative remark or unfavorable departure from a company could potentially close doors to employment opportunities permanently.
Consider the following: 15 out of those 20 people, at some point, leave the company and while they “know you”, they never worked on the same project. This may lead to those seemingly innocuous comments and burning job opportunities at 15 different companies - a considerable percentage of potential job sites in some places.
Also there’s the issue of recruiters. They may look at your CV and if they see a bunch of companies in a short period of time they’ll most likely favour other candidates.
:/ im a bit jaded, so maybe this perspective isnt for everyone. I have abandoned several long term software projects from changing jobs and now try not to invest emotionally in my work projects. To compensate and keep enjoying software development I have a personal project that I am invested in but approach as a long term goal to avoid pressuring myself into completing it quickly and burning out.
I agree that I tend to enjoy my personal projects far more than anything at my company. My typical problem is that I burn out quickly once I get really into anything long term. And frustratingly, I tend to want to work my own projects most when my work gets most stressful.
I guess it’s just hard not to get attached to something you spend so many hours working (and unintentionally thinking) of. But this sounds wise advice.
I empathize completely, sounds like me several years ago :) i hope you find something that works for you.
Sit back, get some popcorn and keep those green eyes open.
