|
I appreciate this emphasis on simplicity and I recommend it to others. I've seen trends in the other direction which I think are dangerous. I notice that as some companies adopted a microservices approach there was a tendency to allow in more technologies than necessary. "Premature polyglot programming" is a disease that afflicts certain startups. While any sufficiently big company will be polyglot, a small startup needs to stay focused on a limited tech stack, for as long as possible. After all, each new technology requires someone on staff who has the skill for that technology, and when your startup is small, your talent pool will also be small, and so it becomes common that you only have 1 person on the team who knows how to run some particular technology (Kafka, RabbitMQ, Redshift, DynamoDB, MongoDB, Tornado, etc). So you end up with a lot of single point of failures, where the "single point of failure" is the single engineer who knows how to run the technology that you've made critical to the company. Be wary. Avoid this if possible. I notice, especially, as the tech industry developed better tools for managing complex devops situations (Docker, Kubernetes, Terraform) there was a tendency from some engineers to think "Nowadays it is easy to run 10 different technologies, therefore we should run 10 different technologies." Be wary of this. Janet Carr's emphasis on simplicity is something we should all imitate. |
Of course larger orgs will have higher tolerance for a wider set of technologies, but this tolerance is not infinite, and choosing tech because that one team was a fan creates staffing problems over time, especially as the original devs move on. Eventually you get “estate sprawl” that’s difficult to manage.
Choosing to minimise dependencies is definitely a (good) choice. The key is the right tech for the task at hand. Equally org-wide “use Oracle for everything” mandates aren’t helpful.
Balancing these at a large org definitely needs good engineering leadership!