4 ms·

> Maybe a great solution will be a mix of OCaml, Lua, Python, Perl, low latency and batches. Your customer does care about how quickly you can iterate new fea

> Maybe a great solution will be a mix of OCaml, Lua, Python, Perl, low latency and batches. Your customer does care about how quickly you can iterate new features over time, and product stability. A stack with a complex mix of technologies is likely to be harder to maintain over the longer term.

evidencetamper 2y ago
That's also an aphorism that may or may not correspond to reality. Not only there are companies with highly capable teams that are able to move fast using a complex mix of technologies, but also there are customers who have very little interest in new features. This is the point of my comment: these maxims are not universal truths, and taking them as such is a mistake. They are general models of good ideas, but they are just starter models. A company needs to attend to its own needs and solve its own problems. The way this goes might be surprisingly different from common sense.
- mexicocitinluez 2y ago
  > these maxims are not universal truths, and taking them as such is a mistake. Amen.
- DrScientist 2y ago
  Sure universal truths are rare - though I think there are many more people using such an argument to justify an overly complex stack, than there are cases where it truly is the best solution long term. Remember even if you have an unchanging product, change can be forced on you in terms of regulatory compliance, security bugs, hardware and OS changes etc. I think the point of the original post is that most important part of the context is the people ( developers ) and what they know how to use well and I'd agree. I'd just say that one thing I've learnt is that even if the developer in the future that has to add some feature or fix some bug, is the developer who originally wrote it, life is so much easier if the original is as simple as possible - but hey maybe that's just me.
JohnFen 2y ago
> Your customer does care about how quickly you can iterate new features over time How true this is depends on your particular target market. There is a very large population of customers that are displeased by frequent iterations and feature additions/changes.
999900000999 2y ago
How big is your team? One person writing a stack in 6 languages is different from a team of 100 using 6 languages. The problem emerges if you have some eccentric person who likes using a niche language no one else on the team knows. Three months into development they decide they hate software engineering and move to a farm in North Carolina. Who else is going to be able to pick up their tasks, are you going to be able to quickly on board someone else. Or are you going to have to hire someone new with a specialty in this specific language. This is a part of why NodeJS quickly ate the world. A lot of web studios had a bunch of front end programmers who were already really good with JavaScript. While NodeJS and frontend JS aren't 100% the same, it's not hard to learn both. Try to get a front end dev to learn Spring in a week...
- DrScientist 2y ago
  > This is a part of why NodeJS quickly ate the world And the other part is you can share, say, data validation code between client and server easily - or move logic either side of the network without having to rewrite it. ie Even if you are an expert in Java and Javascript - there are still benefits to running the same both ends.
- tstrimple 2y ago
  Very much this. The concerns with running a six person team are quite a bit different from the concerns of directing hundreds to thousands of developers across multiple projects. No matter how good the team is and how well they are paid and treated, there will be churn. Hiring and supporting folks until they are productive is very expensive and gets more expensive the more complicated and number of different stacks you have to maintain. If you want to have efficient portability of developers between teams you've got to consolidate and simplify your stacks as much as possible. Yeah your super star devs already know most of the languages and can pick up one more in stride no problem. But that's not your average developer. That average dev in very large organizations has worked on one language in one capacity for the last 5-15 years and knows almost nothing else. They aren't reading HN or really anything technology related not directly assigned via certification requirements. It's just a job. They aren't curious about the craft. How are you able to get those folks as productive as possible within your environment while still building institutional resiliency and, when possible, improving things? That's why the transition from small startup with a couple pizza teams to large organizations with hundreds of developers is so difficult. They are able to actually hire full teams of amazing developers who are curious about the craft. The CTO has likely personally interviewed every single developer. At some point that doesn't become feasible and HR processes become involved. So inevitably the hiring bar will drop. And you'll start getting in more developers who are better about talking through an interview process than jumping between tech stacks fluidly. At some point, you have to transition to a "serious business" with processes and standards and paperwork and all that junk that startup devs hate. Maybe you can afford to have a skunkworks team that can play like startups. But it's just not feasible for the rest of Very Large Organizations. They have to be boring and predictable.

evidencetamper 2y ago

That's also an aphorism that may or may not correspond to reality. Not only there are companies with highly capable teams that are able to move fast using a complex mix of technologies, but also there are customers who have very little interest in new features. This is the point of my comment: these maxims are not universal truths, and taking them as such is a mistake. They are general models of good ideas, but they are just starter models. A company needs to attend to its own needs and solve its own problems. The way this goes might be surprisingly different from common sense.

mexicocitinluez 2y ago
> these maxims are not universal truths, and taking them as such is a mistake. Amen.
DrScientist 2y ago
Sure universal truths are rare - though I think there are many more people using such an argument to justify an overly complex stack, than there are cases where it truly is the best solution long term. Remember even if you have an unchanging product, change can be forced on you in terms of regulatory compliance, security bugs, hardware and OS changes etc. I think the point of the original post is that most important part of the context is the people ( developers ) and what they know how to use well and I'd agree. I'd just say that one thing I've learnt is that even if the developer in the future that has to add some feature or fix some bug, is the developer who originally wrote it, life is so much easier if the original is as simple as possible - but hey maybe that's just me.

JohnFen 2y ago

> Your customer does care about how quickly you can iterate new features over time How true this is depends on your particular target market. There is a very large population of customers that are displeased by frequent iterations and feature additions/changes.

999900000999 2y ago

How big is your team? One person writing a stack in 6 languages is different from a team of 100 using 6 languages. The problem emerges if you have some eccentric person who likes using a niche language no one else on the team knows. Three months into development they decide they hate software engineering and move to a farm in North Carolina. Who else is going to be able to pick up their tasks, are you going to be able to quickly on board someone else. Or are you going to have to hire someone new with a specialty in this specific language. This is a part of why NodeJS quickly ate the world. A lot of web studios had a bunch of front end programmers who were already really good with JavaScript. While NodeJS and frontend JS aren't 100% the same, it's not hard to learn both. Try to get a front end dev to learn Spring in a week...

DrScientist 2y ago
> This is a part of why NodeJS quickly ate the world And the other part is you can share, say, data validation code between client and server easily - or move logic either side of the network without having to rewrite it. ie Even if you are an expert in Java and Javascript - there are still benefits to running the same both ends.
tstrimple 2y ago
Very much this. The concerns with running a six person team are quite a bit different from the concerns of directing hundreds to thousands of developers across multiple projects. No matter how good the team is and how well they are paid and treated, there will be churn. Hiring and supporting folks until they are productive is very expensive and gets more expensive the more complicated and number of different stacks you have to maintain. If you want to have efficient portability of developers between teams you've got to consolidate and simplify your stacks as much as possible. Yeah your super star devs already know most of the languages and can pick up one more in stride no problem. But that's not your average developer. That average dev in very large organizations has worked on one language in one capacity for the last 5-15 years and knows almost nothing else. They aren't reading HN or really anything technology related not directly assigned via certification requirements. It's just a job. They aren't curious about the craft. How are you able to get those folks as productive as possible within your environment while still building institutional resiliency and, when possible, improving things? That's why the transition from small startup with a couple pizza teams to large organizations with hundreds of developers is so difficult. They are able to actually hire full teams of amazing developers who are curious about the craft. The CTO has likely personally interviewed every single developer. At some point that doesn't become feasible and HR processes become involved. So inevitably the hiring bar will drop. And you'll start getting in more developers who are better about talking through an interview process than jumping between tech stacks fluidly. At some point, you have to transition to a "serious business" with processes and standards and paperwork and all that junk that startup devs hate. Maybe you can afford to have a skunkworks team that can play like startups. But it's just not feasible for the rest of Very Large Organizations. They have to be boring and predictable.