"Adding new technology to the project is easy, living with it on production is hard." This is why we should "prefer technology that’s well understood, with failure modes that are known".

"Happiness comes from shipping meaningful work."

http://boringtechnology.club/

I have prepared some guidelines / questions to ask yourself to help a little bit with a process of assessment of new technologies (frameworks, libraries, databases etc.) for a project.

Ultimate question: Do you really need this new thing?

Questions to discuss with your team

1. Is this is really a team decision or we should ask other teams and people inside the company about using it?
2. Why do you need it? What problem you are trying to solve? Is it right tool for the job? Why it is worth it? (Wrong answers: sexiness, just trying new things)
3. Will it bring any business value? Can you describe it?
4. Will it help to deliver project faster or make it more maintainable or with better quality?
5. How long will it take the ROI?
6. Why you cannot solve it using existing stack?
7. Writing custom library, when something exists in Open Source Software? Why?
8. If you want to use it because of better performance. Do you really need that performance? Can you show the data that it can confirm better performance? (for example, reactive frameworks. We are getting ready for a today's traffic or are we predicting scalability problems that may happen in the long term?)
9. How popular it is? Is it easy to find people to hire? Is it backed by big companies? Is it easy to find people using that? How many questions on stack overflow? How many people has it in CV on LinkedIn? etc.
10. Is there someone else in your company using it - how does their use case and findings compare to your use case?
11. Is it easy to find help? Or you will be learning it by your own? How mature it is?
12. Is there a Learning Curve? Is it easy to learn? Does your team is able to specify it? Do you think it will be comfortable for the team working with it?
13. Have you used it in production in the past?
14. Are there any other companies that are using it on production?
15. Have you played around with it, create sample application, and have some notes about it?
16. Is this new thing, another new toy inside your project? Too many tools are hard to maintain.
17. Is your team experienced with new tool already?
18. Are you running few services on production? Is it really makes sense to add very different tool in our stack?
19. How it will affect on your team productivity? Is it easy to find help about it inside your team or company? If you are only one at the team who knows is... it is probably better to avoid it.
20. Cost estimation, is new solution cheaper/more expensive compared to current one?

Document it.

Good 3rd party libraries

(highly inspired by presentation from Adam Dudczak)

1. There is documentation
2. There is access to source code
3. Big activity inside project & stable release cycles
4. There is more than 1 maintainer
5. There are tests or CI tool integrated (check them and coverage)
6. It is easy to integrate lib with your tests stack
7. It is top 5 about github stars library - it is recommended to check other similar libs, sometimes top 1 is not the best one
8. Check issues page. Are there any critical issues? (for example: you can generate same uuid with uuid library) 1.0.0 version released long time ago (it is better to wait for other people to check the bugs for you). Known unknowns vs unknown unknowns. Be careful with fresh tools. Or prepare for contribute to it.
9. Would be good to pass OWASP dependency check, SonarQube has a plugin for it https://github.com/SonarSecurityCommunity/dependency-check-sonar-plugin
10. LICENSE (look carefully at GPL!)
11. There are official docker images
12. It is easy to find help, stackoverflow, github issues etc.
13. It has IDE support
14. It is well integrated with your environment or framework (like our monitoring, linters, CI etc.)
15. It has clean CVE database

Document it. Try to make a log.

New framework, new database, new language etc.

1. If you want to make it for POC - Proof of Concept purpose, write it the same way as for production (very often POC are working on production... ) - but it is not recommended to do it for production anyway
2. Check everything from "Good 3rd party libraries" section
3. Create sample app with few endpoints, remember about:
   • config management
   • monitoring, tracing, logs with tools used inside company
   • API docs like OpenAPI
   • CI/CD, deploy to sandbox
   • add linters
   • building artifact
   • storage connection
   • secrets management
   • dependency management
   • code modularity
   • write any kind of tests, unit, integration, e2e, acceptance, with external service
   • try to profile/debug your app
   • try to do sample load tests
4. During development, try to create "WTF per hour" Log. (weird & confusing things happened during the development)
5. Do some notes/results, what was good, what was bad
6. Another checklist. Does this new thing:
   • was it easy to write tests? is there proper tooling? it should be easy to write a test when you call an endpoint of your backend and mock external service
   • was it hard to instrument code for monitoring and tracing?
   • "allow you to write code that is human readable?, produce code that is optimized for the environment it runs in?, help reduce the size of the application?, allow for the code to be portable and/or extensible?, ensure longevity for the code I am writing?, provide methods to easily test it's APIs are working?" by @steveblue
   • are there good tools for debugging/profiling?
   • was it easy to create modular code?
   • can you compare load tests to something running on production?
7. Discuss the results it within a team & outside the team

Document it. Try to make a log.

Adding new technology to production

1. Cost estimation, is new solution cheaper/more expensive compared to current one?
2. Make a list what do want to achieve to be able to check the results
3. Add proper monitoring, tracing and good metrics. Make some summaries to check your assumptions.
4. If you can, create a WTF / per hour/day log, try to log any hard situation - incident management
5. If you can, create "Is it work?" and log stuff that confirms or not your assumptions
6. Make some summary every quarter

The End

Usually we can solve problems using existing tools. It is not always worth to add anything new to your stack. Most frameworks are very similar anyway but details matter and usually you don't want to be alone on production and discover new bugs there. New technology should prove that there will be good return of value in future.

Hopefully you will find it useful or you can help me to improve the list :) Happy Coding!

References

• The Boring Technology Club by Dan McKinley
• The boring technology behind a one-person Internet company by Wenbin Fang
• Why I ignore the hype (and you should too) by Steve Belovarich
• Good 3rd party library by Adam Dudczak
• Image in the background: “Les Refactoreurs” Gustave Caillebotte, Oil on canvas, 1875