Tech Stack Control – Low Viscosity Development

I’m a [polyglot](https://en.wikipedia.org/wiki/Polyglotism) for sure! Hey, me too! I love being free to pick my favorite new framework and I don’t want to be confined by any one software language or architectural stack. But, there are efficiencies to a well known, well supported language or architecture. Also, there are significant costs to having a disparate group of technologies to proliferate and maintain. It may sound boring but, boring software and systems are also systems that I do not get calls about at 2 AM because they have failed. Or, if a system does need to be addressed at 2 AM anyone on my team is equally capable to address it.

stacks

Conventions

Software frameworks have gotten really good at choosing Convention over Configuration and so too should your development teams. Having a tech stack where there are well defined patterns and conventions helps to lower the threshold for starting a new project, adding a new endpoint to an existing service or adding a new team member. Having fewer, ideally one, ways of solving the same problem or having particular files in the same place for every project can really reduce the effort necessary for any one developer to get their head around an issue. Having good conventions can make you feel like you’re running on top of water rather than trudging through it waist deep. conventions

Adding new Technology

With that said about productivity and reliability, we also need a time and a place for vetting and introducing new elements into our architecture and conventions. These new and shiny technologies should be added deliberately by using mechanisms like Proof of Concept (POC) projects or honest conversations about what this new tech is really solving and how might the problem be solved with our current stack. You may find that the new bit of tech is exactly the right tool for the problem and that it is totally worth adding the educational burden to the team or that the problem could easily be solved using a tool in your current stack that doesn’t require any unnecessary tech ramp-ups. Good places for adding or vetting new Tech:

  • Internal Tools/Dashboards
  • POC or personal projects that can highlight the pros/cons

  • Non critical path processes delivery

    Optimize for Delivery

    You want your teams to be working on actual solutions, ones that your business partners have stated as high priorities, and you want those teams to be happy and performant. Sometimes we may think that zero constraints would be the best thing ever and that nothing would make us more happy, but a couple well placed constants – like a healthy CICD practice or conventions for logging – can free us from spending all of our time reinventing these paradigms each time we have a story to complete.

More Reading: CICD pipeline