Happens everywhere.
In corp I've seen engineers go behind their manager's back to write something in their favourite language knowing it would've been rejected if discussion had happen beforehand.
In corp I've seen engineers go behind their manager's back to write something in their favourite language knowing it would've been rejected if discussion had happen beforehand.
And too often little consideration is given to impact further down the line. E.g., does this tie up your development teams in future doing non-value-adding work to fix breaking changes? What effect does this have on ongoing support costs? How easy is this skillset to hire for? How does this fit in with our roadmap?
But it doesn't matter because I've bolstered my CV and by the time those things become really painful I'll be long gone.
</cynicism>
How can a programming language choice hurt the business through some mechanism other than productivity? You could say that such a behavior is "indicative of poor choices" but that's begging the question.
Programmer hourly rate * amount spent on doing such tasks = project money spent
Now how has the project money spent impacted the overall project costs, compared with the solution that everyone else is using, including the training costs for the rest of team, setting up a new build infrastructure, possible extra tooling support, salary rates for new hires?
Somehow I feel many coders would profit to learn a bit more about business and project management.
You're not understanding me. I'm saying that if the work would have this good business impact with the original language, then doing the same thing with better productivity (with the same worker) is better.
I'm not saying that improved productivity is guaranteed to mean business impact. Just that it either makes a good thing better, or it takes a bad thing and doesn't make it worse. If someone is doing the wrong work, their rate of production is not to blame.
> Now how has the project money spent impacted the overall project costs, compared with the solution that everyone else is using, including the training costs for the rest of team, setting up a new build infrastructure, possible extra tooling support, salary rates for new hires?
Other than 'salary rate', all of that falls under productivity. If all those costs are going up enough to drop productivity, then the entire premise goes out the window! The premise was secretly using a different language to increase productivity. Secretly using a different language to decrease productivity is so obviously a bad idea that it's not worth discussing.
That said, probably more often than not, there’s an actual value in it.
For example: Android was a completely diferent tech stack from google.
Maps: bought
Youtube: bought
Android: bought
What else?
They are still more or less separate software stacks. (Disclaimer: This knowledge is outdated by about 2 years, but a significant change is unlikely. )
Not saying that the extent to which it was apparently done at soundcloud should be acceptable though.
But be aware there are two sides to this coin and you might be the one that needs to learn. My questions are always : is this part of a pattern (conflict, poor performance, bad behaviour?); why don't I want to sit with this person for 2 hours with a coffee and understand whats going on?; why didn't the coffee heart to heart work out?