> Do you also make everyone wear the same clothes, drive the same vehicle, order the same food
I don't think this is an valid comparison. There's a problem called technology sprawl, which is characterized by needlessly increasing maintenance needs and cognitive load and lower development speeds caused by the need to juggle multiple programming languages or frameworks. There is a fixed cost in maintaining each tech stack and even development environment, and you multiply that cost each time you think it's a good idea to introduce yet another programming language or framework.
> Do you also make everyone drive the same vehicle
Good analogy. If, say, your organisation maintains a fleet of cars - it needs to keep them on the road, get them serviced, replace parts, refresh individual cars regularly etc.
How many different makes and models do you support? A small org might decide that it only makes sense to support one. A larger org might have the resources for 3 or 4, so that there is 1 or 2 "general purpose" models, and then other ones suited to specialised tasks.
> But different tasks require cars, other tasks require trucks, vans, bicycles, motorcycles..
No, they don't. You may believe that some frameworks or programming language are ideally suited for some particular tasks, but that is mainly dictated by your prior experience (or lack thereof). The truth of the matter is that a van can very well do the tasks you conceive for a car, trucks, bicycles, motorcycles, etc. If you go with a van, you avoid the problems of having to maintain car, trucks, bicycles, motorcycles, etc. This is called software engineering.
I think that question is more "how many different makes of van can your delivery company afford to maintain?"
Which is an analogy for "how many different programming languages for the same task of serving a web api can you company afford to support?"
The majority of programming languages (c# definitely included!) are "general purpose", i.e. they can be used well enough for almost all tasks. They're not so different as a truck vs. a bicycle.
The issue is not so much "we need firmware in Rust and statistical analysis in R" - that's fair! The issue is more, as others have said, web apps or similar in multiple equivalent languages. This is an overhead. If you take on that overhead, recognise that 1) it has definite drawbacks and 2) for mundane tasks, the advantages aren't large. and 3) chances are your organisation is like most orgs - you don't do all of firmware, statistical analysis and web apps, in house.
Yeah, .NET is a truck and React is a bicycle. Nobody sad you can't use different tools for different tasks.
I'm saying use one tool for one task. One type of truck. One type of bicycle. Maybe some companies need both a small and a large truck. That's all fine as long as you actually need it.
Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet.
> Do you also make everyone wear the same clothes, drive the same vehicle, order the same food
I don't think this is an valid comparison. There's a problem called technology sprawl, which is characterized by needlessly increasing maintenance needs and cognitive load and lower development speeds caused by the need to juggle multiple programming languages or frameworks. There is a fixed cost in maintaining each tech stack and even development environment, and you multiply that cost each time you think it's a good idea to introduce yet another programming language or framework.
> Do you also make everyone drive the same vehicle
Good analogy. If, say, your organisation maintains a fleet of cars - it needs to keep them on the road, get them serviced, replace parts, refresh individual cars regularly etc.
How many different makes and models do you support? A small org might decide that it only makes sense to support one. A larger org might have the resources for 3 or 4, so that there is 1 or 2 "general purpose" models, and then other ones suited to specialised tasks.
But different tasks require cars, other tasks require trucks, vans, bicycles, motorcycles..
> But different tasks require cars, other tasks require trucks, vans, bicycles, motorcycles..
No, they don't. You may believe that some frameworks or programming language are ideally suited for some particular tasks, but that is mainly dictated by your prior experience (or lack thereof). The truth of the matter is that a van can very well do the tasks you conceive for a car, trucks, bicycles, motorcycles, etc. If you go with a van, you avoid the problems of having to maintain car, trucks, bicycles, motorcycles, etc. This is called software engineering.
I think that question is more "how many different makes of van can your delivery company afford to maintain?"
Which is an analogy for "how many different programming languages for the same task of serving a web api can you company afford to support?"
The majority of programming languages (c# definitely included!) are "general purpose", i.e. they can be used well enough for almost all tasks. They're not so different as a truck vs. a bicycle.
The issue is not so much "we need firmware in Rust and statistical analysis in R" - that's fair! The issue is more, as others have said, web apps or similar in multiple equivalent languages. This is an overhead. If you take on that overhead, recognise that 1) it has definite drawbacks and 2) for mundane tasks, the advantages aren't large. and 3) chances are your organisation is like most orgs - you don't do all of firmware, statistical analysis and web apps, in house.
2 replies →
Yeah, .NET is a truck and React is a bicycle. Nobody sad you can't use different tools for different tasks.
I'm saying use one tool for one task. One type of truck. One type of bicycle. Maybe some companies need both a small and a large truck. That's all fine as long as you actually need it.
Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet.
5 replies →
but they all delivers, just that they don't suit your taste doesn't mean it can't