Skip to content

Instantly share code, notes, and snippets.

@kgoralski
Last active September 12, 2019 20:47
Show Gist options
  • Save kgoralski/b6a76bdab9395c320f7172374056dab5 to your computer and use it in GitHub Desktop.
Save kgoralski/b6a76bdab9395c320f7172374056dab5 to your computer and use it in GitHub Desktop.

Questions to discuss within a team

  • Why do you need it? What problem you are solving? Is it right tool for the job? Why it is worth it? (Wrong answers: sexiness, just trying new things)
  • Will it help to deliver project faster or make it more maintainable or with better quality? 
  • Why you cannot solve it using existing stack?
  • How popular it is? 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.
  • 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?
  • How mature is it?
  • Is there someone else in a Company using it - how does their use case and findings compare to your use case?
  • Is it easy to find help? Or you will be learning it by your own?
  • Is There A Learning Curve? Is it easy to learn? Is your team able to specify lerning curve?
  • Did you use it in production in the past?
  • Are there any other companies that are using it on production? 
  • Did you play around with it, create sample application, and have some notes about it?
  • Is this new thing another new toy inside your project? Too many tools are hard to maintain.
  • Is your team experienced with new tool already?
  • Are you running few services on production? Is it really makes sense to add very different tool in our stack. (it is recommended to stick with 1 backend programming language and 1 framework inside the team)
  • 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. 
  • Document it.

Good 3rd party libraries

  • There is documentation
  • There is access to source code
  • Big activity inside project & stable release cycles
  • There is more than 1 maintainer
  • There are tests or CI tool integrated (check them and coverage)
  • It is easy to integrate lib with your tests stack
  • It is top 5 about github stars library - it is recommended to check other similar libs, sometimes top 1 is not the best one
  • 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.
  • Would be good to pass OWASP dependency check, SonarQube has a plugin for it https://github.com/SonarSecurityCommunity/dependency-check-sonar-plugin
  • LICENSE (look carefully at GPL!)
  • Sometimes: There are official docker images
  • Sometimes: it is easy to find help, stackoverflow, github issues etc.
  • Sometimes: It has IDE support
  • Sometimes: It is well integrated with your environment or framework
  • Sometimes: Clean CVE database
  • Document it. Try to make a log.

New framework, new database, new language etc. - Application Sample Stage

  • If you want to make it for POC 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
  • Check everything from "Good 3rd party libraries" section
  • 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
    • Do some notes/results, what was good, what was bad
  • During development, try to create "WTF per hour" Log.
  • 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?
    • are there good tools for debugging/profiling?
    • was it easy to create modular code?
    • can you compare load tests to something running on production?
  • Discuss the results it within a team & outside the team
  • Document it. Try to make a log.

Adding new technology to production

  • Make a list what do want to achieve to be able to check the results
  • Add proper monitoring, tracing and good metrics to be able to check your assumptions. Make some summaries.
  • If you can, create a WTF / per hour/day log, try to log any hard situation
  • If you can, create "Is it work?" and log stuff that confirms or not your assumptions
  • Make a summary every quarter

http://boringtechnology.club/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment