One of the simplest improvements for an efficient environment is to define the technology stack you want to use at your company. A little bit of upfront documentation can safe you endless discussions at the start of a new project. Instead of debating what framework you could use, you check if the one you defined is a good fit. Only if this is not the case you go and search for an alternative. Let’s look how you can define your own stack.
The technology stack is the set of technologies, frameworks and patterns you use to build your applications. It includes the systems you run your application on, how you store your data, how you authenticate your users and can even include your coding guides. You can define as much as you find useful.
Upfront?
As strange as this may sound to some developers, one can define some things before a project starts and still be agile. You don’t need discus everything again for every new project and often a good enough solution is all you need. This is especially true when you create many applications with the same team of developers. Or do you want to learn a new stack with every application?
Where to start?
Start simple and use your current and past applications as a base. What worked well? What would you change? What library was helpful, and which weren’t that useful after all? There are many opinions and not everyone on the team can get its way. Even so, discuss what you would like to reuse and what not.
Documenting it
Make it as simple as possible and keep it as short as you can. You can keep it in a small plain text file as we did for a side project:
* Visual Studio (Community Edition)
* SonarLint
* xUnit
* SpecFlow
* FakeItEasy
* Selenium
* VSTS (CI, Build pipeline, Tasks)
Pending:
* SPA or ROCA
* Angular, React, Vue.js or something else
Your company may demand a more formal description within an official document. If you keep it focused, you can describe your technology stack on 1 or 2 pages – keep it brief like in this excerpt:
We do automated testing to ensure that our application works as expected by using
- NUnit and Moq for unit and integration testing
- Selenium and Specflow for user acceptance tests on the UI
- Netsparker to check for security flaws and misconfiguration on the server
It really isn’t much that you need to write down to profit from a documented technology stack.
Benefits
By defining what you want to use you limited yourself on a selection of tools and patterns. That may seam like a downside, but only at first sight. Your simple list of a few technologies can
- save you money
- minimize the ramp-up time to start a new project
- reduce the knowledge you need to work on your applications
- help you to hire the right people
All this will help you to start the real work of delivering customer value much faster. No longer do you need to reinvent the wheel with every project and can build on top of things you know they work.
You can profit from those benefits even if you don’t write software yourself and let other companies do it for you. Instead of letting them decide what cool technologies they would try on your project you give them specific orders on what you need. That may be less fun for them, but it ensures that you get software you can maintain with a small team of your own people.
Conclusion
Documenting your technology stack is done quickly and can be a great help. But even companies who earn their money with writing software often omit this simple exercise. They prefer to discuss everything from scratch at every new project. Don’t be like them! Go ahead with a little upfront investment and start delivering value while they not yet decided what frameworks to use.
2 thoughts on “Define Your Technology Stack”