How about the context (and examples) which is provided in the first paragraph? Maybe switching a frontend framework or the entire backend to something else? Technical decisions that took a significant amount of resources and time and would shape the company directions for years to come? Has it ever happened in your company? How was the process?
But thanks for the insights anyway! TIL about architects, I've never had that in my career.
Ah, I didn't notice that the 1, 2, 3 were links.
Yeah, I've been a part of a few different switch-out/rewrite/wholesale-replace projects for large enterprises. Here's a high-level overview of how it usually goes down:
Some clueless executive declares that we are going to replace some legacy system so that it can use the latest buzzwords. For example, "We're moving our system to the blockchain on the cloud with microservices."
Some clueless project manager comes up with a plan without involving anyone who knows how to actually do the project, and they present it to the executives, and gets approval for the plan.
Some poor development team is tasked with getting the project done by the delivery date the clueless senior project manager came up with.
The development team gets behind schedule, and the decision is made to add more developers.
More developers are added, requiring the existing developers to train the new developers, which means they are not coding, which means the project falls further behind.
Because there are more developers that need to be coordinated, more meetings are scheduled that take developers await from coding, causing the project to fall further behind.
The first major deadline is missed, then the second, then the third, then the fourth, then the fifth.
The majority of the development team is fired by the executive, as they are blamed for the project not getting done.
A new team is brought in, but this time with new "Technical Leadership," whose main responsibility is to take the blame if the project fails again.
Some poor tech lead then takes a close look at the requirements, schedule, and existing code and realizes the project is not just behind schedule, it might have to be thrown out and restarted.
...return to step #2 and repeat until the project is either done or canceled.
Whoa, that is one roller coaster ride (in a bad way). Sadly, it hits too close to home for me. I wished that big technical decisions like these could've been handled better by the whole team. But I get that it came from the top (management/exec) then devs were just executioners. I'm surprised that the devs didn't say anything (maybe they did?).
Again, thanks for sharing, it means a lot to learn how others did it.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.