1–10 of 28 posts
0. https://developer.app/expectations/code-neutral/
As an engineering leader I have witnessed that oftentimes folks confuse "neat", "cool", and actual business use cases/needs.
If you have a problem that can be fixed by restricting languages, you don’t need to ask hacker news.
If you don’t have a problem that it solves, probably don’t do it.
As you get larger (> 50 engineers in my opinion) you may need to switch things up a bit. I really like the "golden path" methodology described by Charity Majors: https://charity.wtf/2018/12/02/software-sprawl-the-golden-pa...
Short version: pick a set of tools that are fully supported by the organization: projects that use them get backups and deployment and testing and ops and development environments all provided by default.
Teams can stray from that golden path, but they'll need to solve that operational stuff themselves.
UPDATE: I just read https://developer.app/expectations/code-neutral/ and I mostly disagree with it: allowing developers to mix and match any langauges and frameworks they feel like is a huge competitive disadvantage and will greatly damage your ability to maintain software and build features productively over time.
The exception is editors and personal development tools - developers should be able to use whatever works best for them there because it has no impact on other developers - my work in unaffected by your decision to use Emacs instead of VS Code.
But don't make your Python programmers on a tiny team have to fix bugs in a Ruby app because some other developer liked Ruby better!
Start by quantifying what the cost of acquisition is for more developers with said specialization and if that business use case is making you money. As an engineering leader I have witnessed that oftentimes folks confuse "neat", "cool", and actual business use cases/needs.
What criteria is used to determine when it's ok to deviate from in-house langs? What justification is used to prevent deviation at all costs?
Start by quantifying what the cost of acquisition is for more developers with said specialization and if that business use case is making you money. As an engineering leader I have witnessed that oftentimes folks confuse "neat", "cool", and actual business use cases/needs.
I guess what I'm wondering is more about the opposite of the "cool/neat" where orgs either prohibit development in non-standard langs (and that was good/bad) or allow development in non-standard langs (and that was good/bad). What criteria is used to determine when it's ok to deviate from in-house langs? What justification is used to prevent deviation at all costs?
You need to solve all of the following:
- Deployment. How will you run the new thing in production (and QA and staging)
- Upgrades. How will you upgrade to new versions in the future? Who will be responsible for that?
- For databases, backups. How will you backup data? How will you make those backups available for things like data warehouse reporting or replication to teat environments?
- Monitoring. How will you monitor systems built with the new technology, handle alerts etc? How will logging work?
- Profiling and debugging: what tools will you use for this, particularly in production?
- Testing: how will you run the new tech in your CI environments, and your local development environments?
- Development environments: how will you ensure all of your engineers can productively develop with the new platform?
- Expertise and education: who on your team will be the experts to help support the new tech and onboard your other engineers?
- Standards: what common patterns, idioms, styleguides etc will you adopt? Who will make decisions about these, and how will they be enforced?
A productive engineering environment should have widespread, well understood answers to each of these questions for every technology in their stack. The smaller the "approved stack" the easier it is to do that.
As a result of all of this, I think the criteria for introducing something new is to ask if the cost of all of this is justified by the expected improvement provided by the new tool.
That usually means it needs to either make some feature posible that was impossible without it, or it needs to provide a multiple productivity improvement - not just a 1.5x, probably a 3x or higher.
I advised to use Go and most developers were interested and even enthusiastic about it. We proved Go introduction by using it for simulators and testing. But finally the tech lead said "we will never ship anything different than C++ written applications".
My current client also works in embedded tech, but I proposed a polyglot approach and architecture. We ship apps in Go, Rust, C, C++ and even Fortran. Any developer can pick up any language as long as it compiles to Armhf. No one has a problem reading and at least maintaining any code.
There should only be technical limitations and constraints to force down your fellow developers.
Frameworks are a different topic. Web frameworks come and go, and most Angular shops I know became desperate legacy plumbing shops. Only use frameworks that you can replace easily or are willing and capable to maintain yourself.
Earlier quoted context omitted.
I guess what I'm wondering is more about the opposite of the "cool/neat" where orgs either prohibit development in non-standard langs (and that was good/bad) or allow development in non-standard langs (and that was good/bad). What criteria is used to determine when it's ok to deviate from in-house langs? What justification is used to prevent deviation at all costs?
Introducing a new technology - a new language, or new database (like MongoDB), or a new framework is a VERY expensive proposition. You need to solve all of the following: - Deployment. How will you run the new thing in production (and QA and staging) - Upgrades. How will you upgrade to new versions in the future? Who will be responsible for that? - For databases, backups. How will you backup data? How will you make t…
Also to get common libs (e.g. middleware, API definitions) going will be much harder.
The real reason new languages come up in discussion is because of bored developers - that has been my experience at least. And I don't exclude myself from that, it is a major factor in me looking for new work. Now assuming that cynical theory is true, there is an argument to introduce cool stuff to retain good developers - with the understanding that you are shooting yourself in the foot a little bit.
I've wondered about the possibility of allowing a prototype in a "cool" language or framework, with an understanding that it must be replaced soon after by a stable refactor in the existing language set. I think that would appeal to people who want to try something new as well as people who enjoy refactoring, and there would be a kind of extreme programming motivation to the business. I've never tried to get this kind of thing going though.