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.
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.