6 ms·

I'm generally a fan of this, but following this too closely will eventually kill your company. Every currently boring technology was once a new hotness and even

I'm generally a fan of this, but following this too closely will eventually kill your company. Every currently boring technology was once a new hotness and eventually companies that are willing to try new things, or startups based entirely on new things will eat your lunch because they're more efficient, faster, etc. Put another way, this is a very fragile strategy. It consistently protects you from small, limited downsides, while opening you up to the occasional collapse. An organization which is constantly experimenting with new things will pay a consistent cost for all the failed experiments, but they are opening up themselves to huge upsides if one of them works.

sealeck 4y ago
I don't think your strategies are so different – the proposal here is not to _not_ adopt new technologies, but rather to ensure that you consider and manage the risk in doing so (which is very sensible IMO). Further most companies don't make money directly from their technology choices – they make money from the services they provide to customers (which in the vast majority of cases are different things).
youngtaff 4y ago
> I'm generally a fan of this, but following this too closely will eventually kill your company. But isn't that where innovation tokens come in - evaluate the risks of the technologies you're using and know when you're taking a risk IMV too many projects decide to try the new hotness without this evaluation, I've witnessed re-writes in the latest JS framework cost a company millions in lost revenue, also seen product rewrites take years and not deliver something that was much better than before Yes some teams can build create products on top off 'non-boring' technologies but also witness how many every day sites are build on old boring technologies such as Rails
KronisLV 4y ago
> ... eventually companies that are willing to try new things, or startups based entirely on new things will eat your lunch because they're more efficient, faster, etc. I am yet to see a company that is running their apps in Tomcat, Java and MySQL fail badly, even without containers and microservices or service meshes and serverless, since those generally tend to all be orthogonal to getting things done for most of the projects at the scales that my country (Latvia) needs. I think your point could be applicable in two particular cases: - where hype cycles affect the corporate policies and suddenly it's mandated that Kubernetes and microservices are used, because someone either likened their org to another that's 10x larger and has more resources, or just wanted to pad their CV/make their work sound more important; suddenly companies that don't use said tech cannot successfully work on any development contracts with said org - alternatively, where the projects actually need certain new technologies or approaches (aforementioned architectures, tools, things like machine learning etc.) for either large or interesting systems I don't believe that most boring enterprise systems out there will conform that much to either of these, unless you're working for a large org with huge projects. Definitely not for orgs that have technology not be a primary means of getting done (or at least isn't prioritized as such) and for whom a simple CRUD would suffice. Or, you know, governmental projects that are acquired through mountains of documentation and specs, most of which will change anyways. Scale and the industry matter a lot here, there is no one universal truth - in highly competitive markets, you're probably right!
- sanderjd 4y ago
  I have seen such companies fail as they struggle to hire and it becomes more difficult to adapt quickly to more spry competition. If they are in a market without spry competition then it works fine. For instance, for internal applications where there is a top-down forbiddance of experimentation with new things. But even for internal apps, if experimentation is not forbidden, a forward-looking team might start effectively using (and hiring for) newer technologies and eventually get all the budget.
  - devonkim 4y ago
    The other part of the problem is that in a limited hiring pool your competition's labor pool overlaps quite directly with yours and now you need to have compensation packages similar to theirs potentially. I've seen companies have what amounts to the same stack as a large F500 enterprise (Java, Spring, AWS, etc.) and have massive hiring problems, turnover, and especially velocity of features to keep ahead of the big companies. Essentially, if you cannot iterate faster than your competitors sufficiently from the same customer market and hiring pool, you are designed to fail or in best case be acquired by your competition. There is a balance to be achieved between boring technology, boring customer market, boring hiring pool, and so forth when it comes to any company. You need at least two such major advantages to even bother starting a company IMO.
- martythemaniak 4y ago
  Well, in non-competitive "markets" like government services, your failure will just manifest itself in different ways. You will still fall behind more agile organizations, but instead of your company going bankrupt, citizens will increasingly view the government as inept, loose trust, etc. A terrible enough digital infrastructure will eventually become a drag on your GDP and lower your standard of living relative to other places. What's funny about your quotes is that Kubernetes is now 8 years old, very mature, very capable, widely-used, well-understood, with lots of tooling and wide-spread know-how. It is "boring".
  - KronisLV 4y ago

sealeck 4y ago

I don't think your strategies are so different – the proposal here is not to _not_ adopt new technologies, but rather to ensure that you consider and manage the risk in doing so (which is very sensible IMO). Further most companies don't make money directly from their technology choices – they make money from the services they provide to customers (which in the vast majority of cases are different things).

youngtaff 4y ago

> I'm generally a fan of this, but following this too closely will eventually kill your company. But isn't that where innovation tokens come in - evaluate the risks of the technologies you're using and know when you're taking a risk IMV too many projects decide to try the new hotness without this evaluation, I've witnessed re-writes in the latest JS framework cost a company millions in lost revenue, also seen product rewrites take years and not deliver something that was much better than before Yes some teams can build create products on top off 'non-boring' technologies but also witness how many every day sites are build on old boring technologies such as Rails

KronisLV 4y ago

> ... eventually companies that are willing to try new things, or startups based entirely on new things will eat your lunch because they're more efficient, faster, etc. I am yet to see a company that is running their apps in Tomcat, Java and MySQL fail badly, even without containers and microservices or service meshes and serverless, since those generally tend to all be orthogonal to getting things done for most of the projects at the scales that my country (Latvia) needs. I think your point could be applicable in two particular cases: - where hype cycles affect the corporate policies and suddenly it's mandated that Kubernetes and microservices are used, because someone either likened their org to another that's 10x larger and has more resources, or just wanted to pad their CV/make their work sound more important; suddenly companies that don't use said tech cannot successfully work on any development contracts with said org - alternatively, where the projects actually need certain new technologies or approaches (aforementioned architectures, tools, things like machine learning etc.) for either large or interesting systems I don't believe that most boring enterprise systems out there will conform that much to either of these, unless you're working for a large org with huge projects. Definitely not for orgs that have technology not be a primary means of getting done (or at least isn't prioritized as such) and for whom a simple CRUD would suffice. Or, you know, governmental projects that are acquired through mountains of documentation and specs, most of which will change anyways. Scale and the industry matter a lot here, there is no one universal truth - in highly competitive markets, you're probably right!

sanderjd 4y ago
I have seen such companies fail as they struggle to hire and it becomes more difficult to adapt quickly to more spry competition. If they are in a market without spry competition then it works fine. For instance, for internal applications where there is a top-down forbiddance of experimentation with new things. But even for internal apps, if experimentation is not forbidden, a forward-looking team might start effectively using (and hiring for) newer technologies and eventually get all the budget.
- devonkim 4y ago
  The other part of the problem is that in a limited hiring pool your competition's labor pool overlaps quite directly with yours and now you need to have compensation packages similar to theirs potentially. I've seen companies have what amounts to the same stack as a large F500 enterprise (Java, Spring, AWS, etc.) and have massive hiring problems, turnover, and especially velocity of features to keep ahead of the big companies. Essentially, if you cannot iterate faster than your competitors sufficiently from the same customer market and hiring pool, you are designed to fail or in best case be acquired by your competition. There is a balance to be achieved between boring technology, boring customer market, boring hiring pool, and so forth when it comes to any company. You need at least two such major advantages to even bother starting a company IMO.
martythemaniak 4y ago
Well, in non-competitive "markets" like government services, your failure will just manifest itself in different ways. You will still fall behind more agile organizations, but instead of your company going bankrupt, citizens will increasingly view the government as inept, loose trust, etc. A terrible enough digital infrastructure will eventually become a drag on your GDP and lower your standard of living relative to other places. What's funny about your quotes is that Kubernetes is now 8 years old, very mature, very capable, widely-used, well-understood, with lots of tooling and wide-spread know-how. It is "boring".
- KronisLV 4y ago