Choosing a language or framework
When starting a new project, or adding a new module to an existing project, the question of language and framework arises. This is a list of things that I consider when picking a language.
Existing ecosystem
If you already have a handful of different technologies in the project, it is hard to maintain a good level of knowledge for them. Adding another language or framework will not help. It most of the code is stable, so that it never change, and simple enough to be replaced easily when an upgrade is necessary, this is less of an issue. But if you have a lot of code that is still actively maintained by the team, pick something that is already existing in the ecosystem. If the technical requirements are new, say you will build the first native smartphone app for the project, exceptions must be made. If you are afraid that the technology you have won’t be fast enough, write a small test. Guess at the part that will demand the most of the system, implement it for a load test in a technology you already have. Then you will know if you need to introduce more complexity to the project or not.
Knowledge in the team
If you do not have a lot of code in place, but you have the people, let them decide. Not from the shiny toys they want to try, but something they have experience in. Set aside time to experiment on new technology outside of the main project to play with the shiny stuff. That is not for production. If you need to introduce new technology, as in the smartphone example above, make sure that the entire team learns enough to at least be able to fix a simple bug and deploy to production.
Culture of the technology
Languages and frameworks have communities. One of my favourite podcasts, >Code, have panelists who learned Ruby because of the people who go to Ruby conferences. If you need to introduce something new, try to get a feel of the people who already use the technology. Read the code of conduct for the major conferences. Look at the tone in replies to bug reports and feature requests.
Availability when hiring
It you do not have a team, or the team needs to grow, can you hire for the technology? Senior developers should, in my opinion, be able to learn any technology quite quickly. But it might be easier to choose something that people already know and use. I would say that this is extra important if you are not the owner of the product, but helping a customer to get it started.
Patterns and practises
Beside the “people culture” around a technology, there is also a programming culture. Look at the testing frameworks and what patterns people use. Will it be easy to find high quality examples online? Is the standard way of doing things containing patterns that will prevent you from following good practise? An example was a framework that encouraged scripts that swapped lines in configuration files, instead of allowing different configurations when building your target. That practise then also leaked into other parts of our project, wreaking havoc in the setup of originally more sensible frameworks. People will learn from what they do, don’t bring technology with bad practises into your ecosystem. Overly powerful testing tools is also a smell. If you need to “power mock” something, that is a sign of bad design. If all the focus is on integrated tests, that is also a warning.
The actual language
Yes, if you do not have very specific requirements, that you have verified are true, the actual language comes last. For projects that are totally new, where you know you have enough people, and multiple languages are good candidates, you might need to consider the language design. In that case my preference is to look for two things: integrity and decoupling. How easy is it to make sure that my assumptions of the state of the running program is correct? This contains things as dealing with null, memory, types and exceptions. How easy is it to write modular code? That has to do with things as interfaces or protocols, the status of functions, imports and the Liskov substitution principle. What I value in a language change as I learn more.
Writing code for people (including yourself) is harder than writing it for the computer. That is why the people aspect of a technology is more important to me than the technical aspects. That is true also when choosing a language or a framework.
Offer
SAMMAN TECHNICAL TRAINING
Send your team to a course and some of them will remember part of it. Use the Samman method and they will apply what they learn from day one.
Book a meeting if you want to talk to me about maintainable code, to explore how I might help your team. I offer this for free, since I rather talk tech than do sales pitches. Let's explore if I can help you, by trying to solve your problems from the start.
Comment on the blog!
Create a comment by emailing me.
Open an email to start writing.I will then add the comment to the post.