Hacker News Reader

Comment by constantly | Hacker News Reader

This is so bad. The worst of us all, but fun to read about the brinksmanship. The worst line for me was:

“From the founders' perspective, they had a clear stop-loss in place if things didn't work out” with the “stop-loss” being that “[t]he React site would be functional and performant in 6 weeks, and ship in 10. If it didn't, I would step down and recruit a replacement.” It’s just such a horrible thing to put on people, and is in no way a real stop loss.

So things failed, and now we lost our chief engineer, and who knows if they will “recruit a replacement” when they are either gone or on their way out, and recruiting leadership can take so long it’s such a crapshoot. THAT is a “clear stop-loss” to this person? Big oof.

It’s just such bad framing and bad ultimatums and bad people all around that I feel like I’m watching trash tv — and I love it.

View on HN

I don't think it's a viable "stop-loss" so much as it is an attestation of belief+commitment.

Or least, that's what I would think as a manger.

"Wow, you're serious. I believe (a) you're sincere in what you're telling me and (b) you are going to do everything this takes to make it a success."

I'll hook my wagon to that.

I thought the “stop loss” was using the slow Angular site.

Couldn't agree more. I was mildly engaged before the "If it didn't, I would step down and recruit a replacement," but immediately stopped reading.

The statement is wrong-headed in so many ways it invalided anything the author could possibly say after.

Author here. It was a gamble, but I was fighting against a very strong sunk cost fallacy in leadership at the company at the time, and there was a general lack of trust in the entire technical team. I *would not* recommend this approach as a typical way of doing business, and maybe I didn’t do a good enough job at communicating that in the post. This is the only time in my career I’ve delivered this kind of ultimatum.

Everything about this particular situation was exceptional. I focused on the decision to do a rewrite in the post because I thought it was the more interesting part of the story. In hindsight I might have gotten that wrong.

> in so many ways it invalided anything the author could possibly say after.

that's pretty silly. you can be wrong in some areas while still having good insights in others.

Like the thirteenth chime of a clock: not only is it wrong in and of itself, but calls into question everything that came before.

you must be difficult to work with if by one chance a coworker says something that is incorrect, then you never trust them again

I don't think it's really that wrong-headed. What are the choices: (1) march ahead trying to salvage the current design with no clear path forward (other than waiting for the SSR solution), (2) quit right now, or (3) quit in 6-8 weeks if the proposed solution doesn't work (or is not delivered fast enough). The last option is not that bad if the author is hoping to figure it out, especially that the timeline is short and with a quick prototype (which the author did) it's going to be clear much sooner if the new approach is workable or not.

That was the most ridiculous part. So in 10 weeks you would have no Angular site. You would potentially have no React site. You would lose your engineering lead. And the management signed off on this suicide pact?

By how the article is written it sounds like the ultimatum was the author's idea, as their way of securing the founders' buy-in. The ultimatum wasn't the stop-loss, it was the fact that the Angular project would ship if the angular team shipped SSR.

I think the primary reason the management team went along with the re-write is the thing that they had been struggling on for months could be working well in 6 weeks and complete in 10. This must have been a pretty small project - but kudos to the author and team for pulling it off.

To be fair the original also had a 12 week projection. So this 10 week 'estimate' was at that point just that. From a management point of view I would read this as an implicit 'we do this or I quit now'.

I guess if you have been working on something for 10 months, have most of the major pieces together, the team is stable and has a good understanding of the problems, then perhaps it is reasonable to expect that a complete re-write can be done in 10 weeks.

I think when most people say "don't do big bang re-writes", the reason behind it is the current development team unlikely has a complete understanding of the codebase. Once you have a million+ lines, no single person has a complete understanding of how everything works. People leave and new hires come up to speed, people forget how things work, etc., so the understanding of the system from an organizational perspective is rather fuzzy. Starting over in this situation is risky because the organization will inevitably have to re-learn forgotten things, re-implement and re-forget them to get to the same state that it was originally in. Much better to do one piece at a time in this situation.

Author here. This was a key element of our success. The team knew exactly what they had to build, because they had already built it once.

We wouldn’t have been able to hit such an aggressive deadline under different circumstances.

Reply on news.ycombinator.com