> "I joined this company after they'd gone a stretch without any developer, and the bug queue showed it."
I think maybe if you're at a company like that, you should be very cautious in suggestions/timeline/etc about literally anything and everything technical. Certainly much more than you would be at a company that has a basic level of software engineering competency. It's kind of a different world...
Yeah, I'd be reluctant to commit to a hard timeline for a mess like that. Be extremely clear about what they're up against, that it's going to take a lot of time, and that there will probably be unexpected surprises which will take even more time.
At the same time, don't tackle everything at once. Cut it up into pieces, define interfaces between different parts, make sure the behaviour is documented in test cases. That way you'll be able to refactor parts of it while keeping the system working.
Go from working system to slightly better working system. It might seem like the overhead would take longer, but your sanity will save you much more time. You'll be able to quit or pause and maybe implement some new feature for the newly redesigned part, to keep business happy and to show that the refactor does help.
Let's not gaslight ourselves. This guy was clear. The CEO who knows the least about anything shouldn't be changing timelines. The real solution is to fire the CEO and hire another 1500 engineers as that would greatly increase shareholder value at no additional cost.
The second best solution is to just reiterate your original timeline and say NO(even if you do it quietly) when anyone tries to change it. If they keep meddling and trying to get you to work off hours, let them lay you off. The important thing to remember is a CEO and execs are helpless. Don't sacrifice yourself to shield them from their own mistakes and incompetence.
If they miss the deadline, they just spin another lie to the customers.
To this developer, this work was the most important work of his life. To the ceo, firing him before anything is finished and spinning a lie to customers is just another tuesday.
Absolutely. Sometimes executives need to feel the impact of their own poor decisions. Do not accept timelines from people who have no idea of the issues. If they fire you, they're firing the person who best understands their code. Don't let them bully you.
That is a _very_ optimistic view of both the power dynamic at play and that level of accountability executives in that context would face. This is a company that previously had no developer - so being the person who best understands the code is not meaningful. If it was a company where that mattered, they wouldn't have survived without an engineer on staff. This is not a situation where the dev is going to have the actual power to "accept" timelines.
And in terms of accountability/feeling the impact of their poor decisions - the blog is already describing them throwing the engineer under the bus, telling them they need to pull their weight, blaming them for mistakes, etc. Management isn't going to feel the impact of anything. Theyve got a convenient fall guy right there and they're already setting him up to take the blame if stuff goes south.
The problem here isn’t the rewrite, the problem here is toxic management, massive feature creep, unrealistic expectations, etc., etc. You’d have been doomed without the rewrite.
> "I joined this company after they'd gone a stretch without any developer, and the bug queue showed it."
I think maybe if you're at a company like that, you should be very cautious in suggestions/timeline/etc about literally anything and everything technical. Certainly much more than you would be at a company that has a basic level of software engineering competency. It's kind of a different world...
Yeah, I'd be reluctant to commit to a hard timeline for a mess like that. Be extremely clear about what they're up against, that it's going to take a lot of time, and that there will probably be unexpected surprises which will take even more time.
At the same time, don't tackle everything at once. Cut it up into pieces, define interfaces between different parts, make sure the behaviour is documented in test cases. That way you'll be able to refactor parts of it while keeping the system working.
Go from working system to slightly better working system. It might seem like the overhead would take longer, but your sanity will save you much more time. You'll be able to quit or pause and maybe implement some new feature for the newly redesigned part, to keep business happy and to show that the refactor does help.
Let's not gaslight ourselves. This guy was clear. The CEO who knows the least about anything shouldn't be changing timelines. The real solution is to fire the CEO and hire another 1500 engineers as that would greatly increase shareholder value at no additional cost.
The second best solution is to just reiterate your original timeline and say NO(even if you do it quietly) when anyone tries to change it. If they keep meddling and trying to get you to work off hours, let them lay you off. The important thing to remember is a CEO and execs are helpless. Don't sacrifice yourself to shield them from their own mistakes and incompetence.
If they miss the deadline, they just spin another lie to the customers. To this developer, this work was the most important work of his life. To the ceo, firing him before anything is finished and spinning a lie to customers is just another tuesday.
Absolutely. Sometimes executives need to feel the impact of their own poor decisions. Do not accept timelines from people who have no idea of the issues. If they fire you, they're firing the person who best understands their code. Don't let them bully you.
That is a _very_ optimistic view of both the power dynamic at play and that level of accountability executives in that context would face. This is a company that previously had no developer - so being the person who best understands the code is not meaningful. If it was a company where that mattered, they wouldn't have survived without an engineer on staff. This is not a situation where the dev is going to have the actual power to "accept" timelines.
And in terms of accountability/feeling the impact of their poor decisions - the blog is already describing them throwing the engineer under the bus, telling them they need to pull their weight, blaming them for mistakes, etc. Management isn't going to feel the impact of anything. Theyve got a convenient fall guy right there and they're already setting him up to take the blame if stuff goes south.
Sometimes stuff just sorta sucks ¯\_(ツ)_/¯
What’s really hilarious are the companies that treat software like a hardware product.
“We’ll design it, test it, release it, and never touch it again !”
Dear OP,
> "I'm hoping to close them out soon, ideally before I run out of goodwill."
Your goodwill is already depleted, time to move on.
The problem here isn’t the rewrite, the problem here is toxic management, massive feature creep, unrealistic expectations, etc., etc. You’d have been doomed without the rewrite.