>The general success ingredient is putting a small team of veterans on making the new system.
I don't disagree with this approach. But one thing I find is:
Sometimes those veteran teams are heavily invested in existing concepts, tools, and approaches. It makes sense, they have seen these things work and they're proven to some extent.
But it's always not the best choice.... and while the veteran teams often start these projects they often aren't the people to "finish" them as they get pulled away. And it is oh so easy to start projects and make decisions if you never see the outcome / have to deal with the fallout.
> Sometimes those veteran teams are heavily invested in existing concepts, tools, and approaches. It makes sense, they have seen these things work and they're proven to some extent.
This is very closely related to why these veteran teams end up successful. Existing concepts, tools and approaches should be the default; if your company uses Python with MySQL you better have a really, really good reason for your new project to use Rust and CockroachDB.
> while the veteran teams often start these projects they often aren't the people to "finish" them as they get pulled away.
I disagree with this. The veterans are veterans because they've already spent time maintaining the existing systems. They've handled oncall, major bugs, and seen all kinds of stupid shit that happens with software. They'll get pulled onto other projects eventually, sure, but they have a higher chance of getting a system into production in front of users, IMO.
Some changes are better than others. If your product works in python/MySQL then rust probably isn't a good fit. Maybe Ruby or PostgresSQL would be better fits.
If your main product is C or C++ then you should be learning about things like rust. Maybe you decide modern C++ is good enough, but if so you should be working with the C++ committee to push safe C++ (as a C++ developer I'm hoping this comes in C++26... I'm looking at how I can put rust into my code for now).
The point is you should know what the good next steps to investigate are and what are not. Rust and Python are both great tools, but it is never okay to choose between the two on any project - the choice is obvious before you get to choosing. Both tools have other competitors that you perhaps should be looking at though (Rust - ada, C++. Python: ruby, go)
> Some changes are better than others. If your product works in python/MySQL then rust probably isn't a good fit. Maybe Ruby or PostgresSQL would be better fits. [...] Rust and Python are both great tools, but it is never okay to choose between the two on any project - the choice is obvious before you get to choosing.
I actually really disagree with this. Python and Ruby are extremely similar in the problem they solve. If you're using MySQL as a basic OLTP database, and you need a basic OLTP database, you shouldn't use Postgres.
I'm talking organizationally here, not just on a single project. You gain nothing by introducing Ruby to your company that's filled with Python experts. Instead, you introduce a bunch of friction and overhead as developers have to relearn things like syntax, how to set up their development environment, how to do dependency management, testing frameworks, etc...
The time to introduce new tech is when it is fundamentally different enough that it could matter. Maybe you have a bunch of Python code, but there's a certain area that's very performance sensitive: you could look at using Rust, Go or C++. Maybe you have MySQL, but you need a database that's used for complex OLAP queries rather than low-latency OLTP work. There you could look at Redshift, Snowflake or the various Postgres OLAP configurations.
Where experience comes in is knowing when these new tools are worth the overhead they cause. Less experienced engineers vastly underestimate the overhead that comes with introducing new tooling. This even applies internally; for example, if you've used Flask for every project you've done at your company for the past 5 years is it really worth switching to Django?
> The time to introduce new tech is when it is fundamentally different enough that it could matter.
I think you agree more than you realize. GP is essentially saying there are few situations where you will be deciding between Python and Rust on account of organization and technical reasons. However, sometimes you should consider introducing new technologies, but only when you identify that the problem being addressed is much better solved by a new technology, fully aware that this will cause various sorts of friction within your organization.
I disagree. There's no magic to being on call that means you understand something well enough. That's simply not automatic.
Following through with something from start to "finish" is far far more valuable than fixing one off bugs and then doing something else, and then something else.
If anything I think it can lead to a lot of poor assumptions based on very skewed experience.
Depends on the nature of your oncall. If your oncall is just following documented restart procedures when your app gets stuck, you won't learn much. If your oncall involves deep investigation into your system and how it interacts with other components (services, databases) etc you'll learn a lot.
per some sibling comments though, years of experience != veteran, to be clear. There's certainly people who have been working for 10+ years, sometimes even at the same company, and don't really understand what they're working on.
I think it comes down to the personality of the veteran. If they're the "i've seen some shit, so I'll 'architect' the fuck out of this to handle any type of change" type veterans, then it's likely to fail. But if they take their knowledge of how the system has grown over time and architect to handle the types of changes they've seen, then there is likely a greater chance of success.
Personally, I think a having some junior and mid-level engineers on the rewrite is good because it's a good way to see how the system is all put together (as opposed to just one area) and they'll be able to have conversations with the veterans about how the system has evolved as it grew and that is valuable information.
Meh. I’ve met brilliant juniors and worthless veterans. I think it’s more important to recognize brilliance in people… That spark of hard work combined with vision and creativity.
I don't disagree with this approach. But one thing I find is:
Sometimes those veteran teams are heavily invested in existing concepts, tools, and approaches. It makes sense, they have seen these things work and they're proven to some extent.
But it's always not the best choice.... and while the veteran teams often start these projects they often aren't the people to "finish" them as they get pulled away. And it is oh so easy to start projects and make decisions if you never see the outcome / have to deal with the fallout.