I used to be a fan of programmer productivity and having the best tools to express ideas in. In our case, this is not about LISP, but about being able to write 40 lines of SQL in half an hour to solve things that other people reach for 1000 lines of backend language to do. But also trying hard to identify opportunities to simplify and delete code instead of adding another layer of complexity on top every time something doesn't add up.
But I've started to wonder. In some ways I feel "our" area in the company has been a victim of our own success: By doing things in smart/efficient ways, the tasks we've done has become seen as simple, we didn't need to recruit as much, and eventually because of the low number of people occupied on the task in the organization it is seen as easier or less important and we are more vulnerable to churn than larger teams.
I've seen simpler problems getting solved in (what I think is) very inefficient ways and I used to scoff at that. But now I think what they gain is a large robust team, which can handle both churn and have more weight politically in the organization. Solving something inefficiently simply offers a way to have more people do the same task, for redundancy.
In a sense, once an organization hits a certain size it seems that efficiency in a programming language is an anti-feature. You WANT a larger set of programmers to be happily working on something just to have a larger team around the code and redundancy in people. If a programming language / environment allows you to be too efficient, then too few people get the job done and you become vulnerable.
At least, that's the best explanation I have at what's really going on in the industry.
This sounds like the standard "but are they busy?" concern hitting. Folks claim they want folks that are working "smarter" and not "harder." Completely ignoring that that is, itself, hard.
I agree with your general concern. I hate it when, not only do I know that I am in fact lazy, but that is not why I have done less in this case. I genuinely believe the smaller solution is far far preferable. All too often "don't do it" is by far the better option for what so much internal tooling does.
To that end, I push back against you wanting a less efficient language. I think efficiency is itself a trap. Redundancy and general pacing is a good thing. Languages that try and forego that are not doing themselves any favors.
But, and this is fully to your point, if you don't have the spots in your organization that are fully tolerant to mistakes and bad ideas, than you don't have room in your organization to grow. And if you don't have room to grow as an organization, than you probably don't have room to grow the software, either.
You see related issues with operations too. I was contracted to a company using WebSphere, and they had 4 people (including myself) doing very little except tediously deploying applications to the clusters.
So I took a chunk of my downtime and wrote a deployment engine, to eliminate some of the common mistakes, and ideally make things much faster/predictable.
In hindsight I can see why the team didn't like the idea: in addition to the new Perl code that someone would have to support, it was a serious risk to their jobs. If deployments that previously took 2-3 hours of tedium were reduced to 20 minutes of scripting, why would they need 4 people to do it?
I'm still a fan of the things you mentioned in your first paragraph, and your analysis here horrifies me. I really, really, really don't want this to be true, or to be perversely incentivized.
But I've started to wonder. In some ways I feel "our" area in the company has been a victim of our own success: By doing things in smart/efficient ways, the tasks we've done has become seen as simple, we didn't need to recruit as much, and eventually because of the low number of people occupied on the task in the organization it is seen as easier or less important and we are more vulnerable to churn than larger teams.
I've seen simpler problems getting solved in (what I think is) very inefficient ways and I used to scoff at that. But now I think what they gain is a large robust team, which can handle both churn and have more weight politically in the organization. Solving something inefficiently simply offers a way to have more people do the same task, for redundancy.
In a sense, once an organization hits a certain size it seems that efficiency in a programming language is an anti-feature. You WANT a larger set of programmers to be happily working on something just to have a larger team around the code and redundancy in people. If a programming language / environment allows you to be too efficient, then too few people get the job done and you become vulnerable.
At least, that's the best explanation I have at what's really going on in the industry.