#4 - Wrapping it up & a stack at scale (Topic: “Deciding on a tech stack” - 4 of 4)

The last three weeks we have gone through the following topics:

• Listen to the project, to ensure that we understand the full scope so we can set the correct stack - https://www.dhirubhai.net/pulse/1-listen-project-like-really-topic-deciding-tech-4-wang-hansen/
• Breaking down a tech stack, to ensure we find different components that together can accomplish the scope with maximum synergy - https://www.dhirubhai.net/pulse/2-breaking-down-tech-stack-topic-deciding-4-oliver-wang-hansen/
• Test before you invest, to ensure that all of the last bits of unknowns goes bye-bye and you don’t just “believe” that it works - https://www.dhirubhai.net/pulse/3-test-before-you-invest-topic-deciding-tech-stack-4-wang-hansen/?

So where to go from here?

In this last and final article about deciding on a tech stack I will try to shed some light on two things that essentially are on the side of this topic, but still some important factors. Furthermore, I will round off with one of the ways I work every day with a wider tech stack to help me guide projects through the company I’m currently a part of.

#1 Team and stack

A topic I haven’t covered that much yet is team and stack. It’s ofc a very good idea to ensure that the stack you want to build your product in that your team or you as a developer can produce it in. It’s always quite an investment to go and learn new technology - and yes this is even though “I can just run this one command line, and then it works…”. On the other hand, it’s also sometimes the right thing to do. Some tech teams easily get stuck in the past without moving forward and therefore aren’t aware of the smarter ways to do things.

#2 Updatable, maintainable, and transportable

These three concepts would be big enough to cover a full article each self, but I still believe it’s important to just very briefly throw them into your thought stream when thinking about deciding on a tech stack.

• Updatable - Ensure that the technology has a good release cycle for updates, so it doesn’t get outdated.
• Maintainable - Is the tech you are choosing easy to maintain? If not, then you are in for a ride.
• Transportable - This last one a lot of people forget about, but one I personally know is extremely important for your tech to survive longer. How easy is it to transport your tech and stack to a new server or client? If it’s hard or very hard, then there is a very high likelihood of your product dying when the next move comes.

The agency model - "A stack at scale"

The final wrap-up topic that also could be a full series of articles would be to set a tech stack for a digital agency. This topic has…n more depth due to the complexity of x clients. The topics and concepts that I have covered in the previous articles are ofc still as correct for an agency (well a good one at least, my opinion) as if you only are creating one product.

The way I on a daily basis work with our tech stack in the agency is first and foremost in an open way in order to let our development team grow and expand their knowledge, and the services that we can offer our clients in an ever-changing landscape of new tools and tech. We as an agency are a mid-sized Danish company with 60 employees whereas around 30-40% of us work directly with programming. On a regular basis, we have around 10 active (as in production) clients and are maintaining around 30 clients at all times.

In general, during the last couple of articles, I have focused on trying to be as technology-agnostic as possible. In an agency set-up like we have, then it would be a dangerous game to be truly technology-agnostic due to our number of teammates and clients. Let’s just play it out. Let’s say we decided to be completely technologically agnostic, what would happen within a year would be that we (most likely) would have 10 active client products in 10 different technologies - and so on and on as the years go. This wouldn’t scalable and we surely wouldn’t be able to support our clients as best in class in what we do. So, we work with a concept of a primary tech stack. The primary tech stack consists of a couple of Frontend based frameworks and two different backend technologies that each can support different scopes for web-based applications.

But! The tech stack is not static, we are always evolving and tweaking our primary stack to ensure that we aren’t going to be a dusty old agency. We do that by ofc always researching and monitoring the “market” of technologies and then testing them on the following diagram.

Basically, we want and need our tech stack to be placed in the bottom right area to ensure that we don’t have to make the “sorry we can’t support your stack anymore” or “sorry, we know you want this feature, but we have to re-write the entire base in a different framework” - calls to our clients. Then you might think “but how often do these types of technologies come by?”. What you need to understand is that it doesn’t have to be the foundation such as the programming language or framework that you change or add but the add-on packages or tools around the stack. In 2021 we have fully adapted three new add-ons to the stack. So, with the above and a couple of other articles, I hope you feel that you are dressed to impress next time someone asks you about why you chose exactly that tech stack that you chose.

I also hope that this series of articles have been helpful in regard to nailing some concepts that have taken me many years to get a full grasp about. Luckily the field where we work in things changes so fast, so in a couple of years, we might be able to add a couple of extra topics to this series. If you still don’t feel 100% knowledged-up on the topic, then please don’t hesitate to ask your question(s) in the comment field or slide into my DM and ask them there. Next month I will pick another topic to write a series of articles about, so if there is a tech or digitization topic you would like to know more about also just comment below.

Good luck with the tech stack - have a nice week! ????