Growing your Tech stack: when to say no

  1. They run on your own machine, though a whole team can adopt them, boosting productivity. If not widely used, switching environments is harder and you might compromise uniformity, but it is often a worthwhile trade-off.
  2.  Deployment infrastructure tools (monitoring, logging, provisioning,
    building executables, deploying) are a moderate risk. They automate
    tasks for the whole team, which means the whole team (and
    deployment) stops if it breaks. But they reduce risk in
    production/deployment compared to manual set-up and
    troubleshooting. They constitute a hot area for development and you
    risk falling behind your competition without them.
  3.  A new programming language is also a moderate risk. Each language
    calls for new build tools, libraries, dependency management,
    packaging, test frameworks, internal DSLs. More than one person must
    learn them, or you get code no one but the developer understands.
    Getting your team on board, fast becomes your responsibility. You can
    mitigate the risk by carefully isolating the experimental code so that it
    becomes replaceable. Consider the tooling and documentation
    available before you select a language and whether other people have
    integrated it into a stack like yours (and written about it). The more
    languages you use, the greater the cognitive overheads when

1 thought on “Growing your Tech stack: when to say no”

Leave a Reply

Your email address will not be published. Required fields are marked *