3 ms·

I’ve seen a lot of programmers/architects who created way to complicated solutions. Distributed microservice applications, nosql, and so on. New technologies th

by andix 4y ago

I’ve seen a lot of programmers/architects who created way to complicated solutions. Distributed microservice applications, nosql, and so on. New technologies that seem cool and useful, but make stuff much more complicated then it needs to be. Without real benefits. „But we can scale from 500k to 50 million users now“, which usually doesn’t happen. But what does happen is, that the system gets too complicated and too hard to extend or fix bugs.

sopooneo 4y ago
I struggle mightily with this in managing projects. My instinct is to use solid boring tech, and maximize chance of delivering on time. But I've found that: 1.) No one writes blog posts about using old boring stuff and meeting expectations. And such blog posts can contribute to recruiting and even, indirectly, sales, by helping your company get general press for being "on the cutting edge." 2.) You can potentially get better overall results even if the new tech has more gotchas and unknowns, because certain developers will knock themselves out to deliver on time and prove you were right in trusting them with the platform/language decisions. But you have to pick very wisely on this and keep in mind such devs may immediately lever their experience on the new tech to get a new job and leave you with a team of juniors that wander lost without their guru.
- andix 4y ago
  I think it’s still possible to use some modern aspects in combination with boring old tech. One thing I found useful is: try to build something that is boring old tech, but the boring tech can be switched out easily. Like a monolith that can be also split up into micro services (via a build flag).
- whstl 4y ago
  I don't think "solid boring", or even old, is necessarily bad for recruiting. Typescript and Golang for example, are relatively new-ish but still solid and boring, and have significantly much less gotchas than older established tech like, say, Rails. I don't do Java, but I see it getting a bit of a renaissance. Either because of new features or because people are moving to Kotlin (yep for backends), which is a different language but still has the "solid boring" feel to it. It is tough to hire for devops, though. The currently experienced people want to work with more complex infrastructure. Maybe we need a few more years to see those people getting burned and deciding they don't want to life an exciting work-life anymore.
SoftTalker 4y ago
And there's a vast difference between building a system wuth allegedly scalable components, and actually scaling the system to run. It's way more than just using nosql. I'm also one who uses boring old technology. Mostly relational databases and LTS operating systems. May not make for interesting blog posts but I'll take that over being called at 3:00AM because some microservice isn't working.
- andix 4y ago
  Exactly. Usually the bottlenecks will appear at places you didn’t expect them in the first place. So I tend to build a system that can handle the load that is expected, and some reasonable scaling (maybe 5x to 50x more load). If your product grows way faster then expected (1000x), you will probably have way more budget, and be able to do it even better.

by andix 4y ago

sopooneo 4y ago

I struggle mightily with this in managing projects. My instinct is to use solid boring tech, and maximize chance of delivering on time. But I've found that: 1.) No one writes blog posts about using old boring stuff and meeting expectations. And such blog posts can contribute to recruiting and even, indirectly, sales, by helping your company get general press for being "on the cutting edge." 2.) You can potentially get better overall results even if the new tech has more gotchas and unknowns, because certain developers will knock themselves out to deliver on time and prove you were right in trusting them with the platform/language decisions. But you have to pick very wisely on this and keep in mind such devs may immediately lever their experience on the new tech to get a new job and leave you with a team of juniors that wander lost without their guru.

andix 4y ago
I think it’s still possible to use some modern aspects in combination with boring old tech. One thing I found useful is: try to build something that is boring old tech, but the boring tech can be switched out easily. Like a monolith that can be also split up into micro services (via a build flag).
whstl 4y ago
I don't think "solid boring", or even old, is necessarily bad for recruiting. Typescript and Golang for example, are relatively new-ish but still solid and boring, and have significantly much less gotchas than older established tech like, say, Rails. I don't do Java, but I see it getting a bit of a renaissance. Either because of new features or because people are moving to Kotlin (yep for backends), which is a different language but still has the "solid boring" feel to it. It is tough to hire for devops, though. The currently experienced people want to work with more complex infrastructure. Maybe we need a few more years to see those people getting burned and deciding they don't want to life an exciting work-life anymore.

SoftTalker 4y ago

And there's a vast difference between building a system wuth allegedly scalable components, and actually scaling the system to run. It's way more than just using nosql. I'm also one who uses boring old technology. Mostly relational databases and LTS operating systems. May not make for interesting blog posts but I'll take that over being called at 3:00AM because some microservice isn't working.

andix 4y ago
Exactly. Usually the bottlenecks will appear at places you didn’t expect them in the first place. So I tend to build a system that can handle the load that is expected, and some reasonable scaling (maybe 5x to 50x more load). If your product grows way faster then expected (1000x), you will probably have way more budget, and be able to do it even better.