A tech stack is the set of languages, tools, frameworks, and utilities that are used in the development and management of a software system.
Tech stacks provide a glimpse of a product’s philosophy and architectural approach. This is an invaluable tool to attempt to reverse engineer how the team operates.
However, tech stacks provide just a glimpse. By relying too much on them, we may wrongly judge the robustness of the system. People can write lousy software using the most modern technologies and tools. Similarly, people can write awesome software using slightly dated tools.
What the technology stack does not reveal is how the problem is being solved. Teams take clever approaches to architect software for scale, for extensibility, for performance, for fault tolerance. By itself, the tech stack does not provide insights into these.
We come across engineers who thumb their nose at specific technologies. It is more interesting to examine what has been built on top of these specific technologies. You may find awesome frameworks and solid architectures that will be a pleasure to learn and to work with. Don’t judge software by its tech stack alone.
When we engage with a client, we spend quite some time thinking about what are the objectives the client is trying to solve, in the immediate future but also in the longer term. We pick a stack that is most likely to minimize technical debt for the long term.
Very often, the client already has a techology stack selected. We analyze this to tease apart how the software has been architected and then we adopt and adapt this tech stack to their future needs. We still bring in our frameworks of devops, of multiple environments, of automated QA, of collaboration to bear. A change is recommended only if significant technical debt needs to be paid back.
Here’s our preferred tech stack: https://stackshare.io/ignitesol/ignitesol though we are working in multiple other technologies including NodeJS, Angular, AngularJS, ReactNative, PHP, ExtJS among others.