3 ms·

I don't disagree with your pitfalls, but I do think we're working to avoid them. To your first point, "The decision seems to be primarily a software architectu

I don't disagree with your pitfalls, but I do think we're working to avoid them. To your first point, "The decision seems to be primarily a software architecture one...", this project has had involvement of the whole engineering team since the beginning. The whole org is on board with this change. It's definitely not happening in a silo. > This is definitely the second system effect. It's going to take years to make this thing reliable and sunset the old product. I hope not, but obviously we're not done yet, so I can't say how long it will end up taking to completely decommission the Python 2 app. What I can say is this: there are aspects to this project that are _simplifying_ our system and, for what's left moving from Python to Go, our intention is to port the business logic as close to a straight up port as we can get. > - They're porting over the logic? Even if this is actually the right move, wouldn't a clean-room implementation potentially give better outcomes? _That's_ second system effect, to me. We can't change everything and fix every problem now, so we're focusing on the changes that will help us move from Python to Go faster. > - Why are they continuing to use App Engine if the writing's on the wall for 2024? I don't think Google Cloud is disappearing in 2024, for one. Beyond that, again, we're not changing everything about our architecture. The way our data is stored is staying the same.

scottrogowski 7y ago
> The whole org is on board with this change. It's definitely not happening in a silo. Given the seemingly strong chorus of voices responding with cautionary tales about why you might want to rethink this plan, and the number of engineers in your organization, it seems more likely that you have some dissenting voices who have either been too scared to speak up or have already been shot down.
- dangoor 7y ago
  What I meant by "the whole org is on board" isn't that there weren't other opinions. There have been multiple opinions on almost every decision we make (and we have an open process and document our decisions in a style very much like this one[1]). In the end, it's not about "shooting down" alternatives, since that's loaded language. It's about making what we think is the best choice we can with the information available to us. Even in this thread, there's a chorus of voices sounding caution based on their limited information of what our situation looks like, but there are others who see why we're doing this, based on the same limited information. We absolutely do know the risks of this project, which is why we're doing this as incrementally as possible. [1]: http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions http://thinkrelevance.com/blog/2011/11/15/documenting-archit...

scottrogowski 7y ago

> The whole org is on board with this change. It's definitely not happening in a silo. Given the seemingly strong chorus of voices responding with cautionary tales about why you might want to rethink this plan, and the number of engineers in your organization, it seems more likely that you have some dissenting voices who have either been too scared to speak up or have already been shot down.

dangoor 7y ago
What I meant by "the whole org is on board" isn't that there weren't other opinions. There have been multiple opinions on almost every decision we make (and we have an open process and document our decisions in a style very much like this one[1]). In the end, it's not about "shooting down" alternatives, since that's loaded language. It's about making what we think is the best choice we can with the information available to us. Even in this thread, there's a chorus of voices sounding caution based on their limited information of what our situation looks like, but there are others who see why we're doing this, based on the same limited information. We absolutely do know the risks of this project, which is why we're doing this as incrementally as possible. [1]: http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions http://thinkrelevance.com/blog/2011/11/15/documenting-archit...