How do you choose your technology stack? As a web development agency
You cannot mention a tech company without bringing into discussion its technology stack. Whether you’re a businessman or a technology enthusiast.
That is the sum of programming languages, frameworks, tooling, and paradigms the company uses to meet its clients’ business goals.
Independent of your background, whether it is technical or not, you can’t help but wonder why there is so much diversity when it comes to the tech stack.
They should have already come to an agreement on what is the best tech to use by now, shouldn’t they?
Yes and no.
The decision-making process is influenced by a series of factors. These factors weigh differently depending on the dominating stakeholder perspective.
Traditionally, the decision responsibility is delegated to the technology department. Here, people will mostly debate performance, paradigms, community support, and personal preferences. In some companies, representatives from the business branches might contribute with their perspectives on talent availability, market demand, or industry and niche insights.
If the latter doesn’t happen everywhere, I advise you to start immediately.
After all, the tech stack is a business decision as much as it is a technical one. A thought-through stack can help the developer as it can make it trouble-free for the recruiter to attract talent and the business development representative to bring new, enticing projects.
What exactly is a tech stack?
The tech stack contains all the technologies that we use on a regular basis to meet a business goal. It can be servers, clouds, databases, programming languages, frameworks, or libraries. It can also be methods and methodologies.
Stacking one on top of each other, starting from closest to the metal and building further up away from the machine and closer to the programmer. So that he uses high-level programming languages and ready-made functionality to put together complex applications to serve his users' needs.
To better illustrate the image, think of a basic web development stack:
You can have an Amazon Web Services cloud subscription that provides you access to highly available server infrastructure.
Then you use a PostgreSQL database to persist your application data.
Let’s also use PHP to interrogate the database for the desired data.
But since you’re at it, you’d better use a web framework, such as Laravel, in order to:
- provide recurring functionality such as handling user requests and
- organizing your application code in a way that is both efficient as well as developer-friendly.
You can also make use of the available knowledge in the field and take a domain-driven approach to your codebase. Let’s go for a hexagonal architecture too.
As we’re approaching the front end, we need to decide what service we use to retrieve the data from our backend. Let’s settle for a REST API for now.
You can then write your user interface in either React, Vue, or Angular. You’ve got so many choices.
Who’s making the choice then?
We need to shift the discussion from a purely technical discussion to a more stake-holder oriented perspective.
It’s wise to think that people who work, first-hand, with technology, should have the first say. These are the individuals who will experience on a daily basis the implications of their decision.
A new, strongly hyped programming language will come along with the challenge of scarce or incomplete documentation and poor community support. It can also generate higher costs in the short run. The development team might have to make up for the young ecosystem by developing its own libraries and frameworks.
The human resource department should also have a say.
Let’s say you decide for Clojure to be the main pillar on which you build your stack. While rich, its community still does not compare with those of PHP, Java, or Ruby, for example.
This can translate into longer fulfillment times for recruiters, or even a complete strategy overhaul — Think about attracting specialists from other fields and converting them to your current stack. This implies a different set of challenges altogether.
It’s worth mentioning that geography is a very powerful factor in specialized resource availability (at least prior to the COVID-19 remote work revolution).
What does this mean?
For example, there are much more PHP developers available in Europe than on the North American continent where Ruby is the preferred language. Most probably because of the larger startup scene which prefers Ruby on Rails for its fast prototyping capabilities.
The business development team should have a say too.
Some prospects are also factoring in the technology stack when choosing a development partner. Some reasons for this are:
- A pre-existing legacy codebase
- Industry-specific recommendations
- Preconceptions
- Hype
If you’re operating in an industry where your clients are stuck on “enterprise” languages such as C# or Java, your business development team could have a hard time selling them on Ruby for a change.
So far we’ve seen how software engineers, business developers, and human resources professionals are all affected by the technology stack.
Got it. It’s important.
But how do we come by it?
It’s important that all stakeholders have a say. The more the merrier.
But there’s a catch.
You need to explicitly designate the final decision-makers and have a capable moderator too. Otherwise, social loafing will occur. This means, everyone will expect everyone else to act while they stay by.
The moderator's role should go to the technical leadership in the organization.
Make sure you source as much input as possible from a diverse audience. This way we make sure we cover all bases as well as secure a great level of commitment from the team.
The moderator will present the format (focus groups, workshops, etc), moderate the conversation, collect, process and present the output to the decision-makers.
Document it.
The approach I took with my company accounts for a mix of current capabilities, and personal development goals. The impact on the business model is also important. Some of our target sales channels require a very specific set of expertise.
A straightforward approach is to moderate the process by asking meaningful, open questions. And listen.
Below are the questions I used to learn more about our untapped potential.
What can my team do?
A logical first step is to assert the current expertise of your current team.
For example, you might have an expert Perl team. While it is not the freshest tech out there, a skilled team, well-versed in its technology of choice, will have a greater velocity and better output quality than a novice team on the newest tech.
How will it impact recruitment?
If the targeted skills are scarce in the market, the decision will increase the effort of the recruitment team. Even if you have all the necessary workforce momentarily; if your main stack is Perl, replacing a team member or scaling up the team can be challenging for the human resources department due to the declining popularity of the stack.
Does it play well with my business goals?
For example, for new technologies, it means there are little to no large legacy codebases in the wild. If this is what you’re after, businesswise, it makes no sense to put all your eggs in that basket.
Will it make my team better?
There are technologies for which the sheer process of learning makes one a better developer. Take Swift programming language, for example. Being a new entrant, its design reflects the learnings from a few decades of practice.
All that is new and unfamiliar will stunt one’s velocity for a while.
Oftentimes, introducing new technology will make up for the initial delay through increased efficiency brought by expanded knowledge, lateral thinking, and enhanced problem-solving capabilities.
Changes should be incremental and complementary to one’s current capabilities.
Does everyone see the added value?
It could be the single best technology that will make everyone a better programme. But if your team gets the wrong message or doesn’t understand how it is worth trading some comfort, at least initially, it won’t happen.
elm-lang is the better alternative to front-end development at the moment. Yet it takes a radical turn towards what modern front-end means. I’d have a much easier time switching whole teams from Vue to React, for example, than to Elm.
That’s because t’s a leap, not an increment.
The 3S: Stable? Safe? Scalable?
Or: Is it future-proof?
What company in the right mind would start a new project knowing its codebase won’t make it to launch time without becoming obsolete.
In the early days of Angular 2 I’ve been in a team where we had to rewrite good portions of the application several times. Through at exactly 4 release candidates before we launched.
This translated to unnecessary spending, based on a risky bet: oogle is making the right move.
Leading into the first S…
Stability:
How does it move forward?
Angular made a giant leap around 2015, rolling out a completely new framework.
Facebook’s React, on the other hand, had seen innumerable versions, most of them packed with breaking changes.
At the opposite pole, we have Vue which even with its most recent update, to v3, is still compatible with its predecessors.
Is the community actively contributing to the ecosystem?
Do not confuse support with popularity.
Popularity can be a lagging indicator for advertising efforts.
Compare Facebook’s push for React to Sun’s Java campaign from the 2000s.
In the worst-case scenario, a strong community can provide an alternate path to the owner’s roadmap for the userbase. See what happened with Google and Rob Eisenberg, for example. Rob, who also worked on Angular 2, left and put the basis of Aurelia when their ideologies couldn’t converge anymore.
Otherwise, a strong community will often mean better documentation, increased StackOverflow activity, curated libraries as well as richer alternatives to these.
Moving on to a more technical perspective.
What are the language features that help with refactoring?
It is estimated that developers spend, on average, 33% of their time dealing with technical debt.
Some codebases are easier to refactor than others. What makes the difference?
- Static analysis — the automated analysis of source code without executing the application
- Type safety — the compiler will validate the type while compiling, and throw an error when we try to assign a wrong type to a variable.
- Automated linting and fixing
What are the best practices?
This question could also be phrased as: Can we make use of the collective knowledge in order to:
- Ensure a level o maintainability by design
- Make it easy for new professionals to understand the codebase
Safety:
Is it secure by design?
Some programming languages are more prone to user-generated security concerns.
In this regard, the C language is infamous for the many ways in which the user can screw up.
Just to name a few: buffer errors, permission, and access control issues, out-of-bounds read, and information leaks.
Later, when assessing web frameworks, we need to understand how it protects from exploits such as cross-site scripting, SQL injection, broken authentication, etc.
How does it manage its dependencies?
To this point, we have the example provided by Deno which positions itself as a more secure version of Node.
Deno allows the user to consciously grant permissions to dependencies, individually. Additionally, it provides built-in auditing capabilities and promotes the idea of a curated, well-maintained list of dependencies instead of scattered, deprecated alternatives.
Scalability:
What are the known performance bottlenecks?
Let’s discuss Twitter’s decision to switch from Ruby to Scala around 2011.
Much debate was caused by this and people used this switch as an argument to deem Rails a hard-to-scale technology.
What we also need to take into consideration is that some programming languages have an affinity for a specific type of task.
Scala is a much better fit for real-time messaging on a large scale. — The way Twitter does.
Should have Twitter started on JVM from the beginning? Probably not. Rails is a much better fit for rapid prototyping.
Forecasted talent pool growth
There are numerous stories describing how business went from running 20 servers in production to only one by switching from Node to Elixir.
On the other hand, the Javascript talent pool is forecasted to increase at an exponential rate making it easier for everyone to recruit JavaScript programmers than would be to find Elixir experts.
In the long run, it is always recommended to put in balance the two aspects.
Some tech stacks create a competitive advantage.
Some industries have a declared preference for a certain stack.
Within Fintech you’ll often encounter a Java-centric community. If you’re big on Java, you’ll have better credibility when approaching potential clients in this industry.
More on the competitive advantage
Let’s have some fun. Let us apply a resource-based view of internal strategic analysis. We will take our stack through the VRIO (Valuable, Rare, Imitable, Organized) framework in order to understand how our tech stack can help or hinder the business.
Let’s take the Java example above:
✅ Valuable: As aforementioned, Java is a highly popular stack in the enterprise world.
❌ Rare: Its popularity makes it a popular choice with many developers and organizations worldwide making it abundant.
❌ Imitable: Its C-like syntax along with the generous available educational content makes it easy for newcomers to reach working proficiency.
✅ Organized: Has a track record in providing added value to the enterprise, has extensive documentation, and a clear pathway for organizations to adapt and implement in their client’s companies.
Whereas if we were to take Haskell:
❌ Valuable: Haskell doesn’t have a niche in business yet. This doesn’t mean it doesn’t have intrinsic value, it’s just that you’ll have to work harder to motivate your choice in front of a buying audience.
✅ Rare: Haskell in production is rare. At least for web applications. This makes it an advantage from a competition point of view. A client with a Haskell codebase has fewer options to choose from when it comes to a technical partner.
✅ Imitable: While it doesn't stop one to learn, it is a much more intimidating option than our previous example, Java, due to its uncommon syntax paradigm.
❌ Organized: The ecosystem is yet to be mature enough for business. Its current applicability rather resides with academia. This means that tech and business leaders have to pave the way themselves.
In order to have a true competitive advantage, a resource has to be rare, hard to imitate, valuable, and organized.
What bottlenecks could you encounter?
Resistance from the team
If the change is too drastic or presents too little perceived value, your team could silently reject your suggestion or downright oppose it.
To give an example — Many years ago, I failed several times at moving a small team from jQuery to a modern frontend framework.
I’ve tried everything. From backbone.js to angular.js and then react, with no success.
Here’s what went wrong:
- They were already heavily invested in their current stack. They had readymade starters, complex build flows, and even custom rudimentary state management systems meant to work well with jQuery.
- Hence the perceived onboarding cost was enormous. It meant dropping years of work all at once.
- At first glance, the added value can be slim. One practically achieves the same, but with extra steps.
I’ve only had success after I showed them Vue. Here’s what I did this time:
First of all, the framework helped itself by being the easiest of the bunch to integrate into a legacy codebase.
This has eventually led to a melting pot of vue.js, jQuery, and vanilla functionality, bound together by custom-made lifecycle hooks. Making the codebase even harder to maintain. A story for another time.
In order to prove the added value I did the following: I redid a fairly complex search widget developed by one of my colleagues entirely in Vue.js.
I compared the UI-Driven approach employed by jQuery to the pure data-driven approach enabled by Vue.
The code was much more readable.
We all agreed the code was faster and more maintainable too. This was the moment that everyone recognized the need to explore to move on.
The lesson here is to understand that not everybody will have the same context and understanding as you. If you want people to see your point of view, you have to let them in.
Hype trains
You might encounter an audience that is heavily skewed in favor of a specific technology.
The job market, for one, can heavily skew developers by giving them the false impression that if they want to be hireable in the future, they have to learn the number 1 most sought-after programming language.
Advertising and authority-rich backers will make businesses lean towards one stack or another.
In this respect, React is today’s Java.
Subjectivity can be defeated by using instruments such as an exhaustive pro and cons list, benchmarking, or by exposing the cognitive biases at play and working through them.
Expectations mismatch between stakeholders:
The development team wants to work with the latest hype technology to keep things exciting while the management wants to stick with the battle-tested solution.
This is the sort of situation where is important to create a safe space for conversation between stakeholders in order to find a middle way.
Lack of organizational capabilities for change management
Starting is one thing.
It’s critical that the organization is also prepared to follow through with a plan from declaration to implementation and evaluation.
When is the right time?
The stack discussion doesn’t have to be settled in one, big step. Some consistency is desired but the stack will evolve.
Like time and people change, so does technology.
The start of a new project is a good opportunity to introduce an incremental change, assess success, and if all goes well, promote it as an organization-wide tech that can be safely employed for future projects.
Is the effort worth it?
Yes.
There are many advantages:
For the team it could mean:
- Increased velocity
- Better documentation
- Faster onboarding cycles
- Happier developers
- Better tooling
- Increased code quality
While the clients will have:
- Faster time to market
- Future-proofed products
- Performant products
- Better support
- Increased trust
- Strong security
And business:
- Streamlined recruiting
- Increased marketing capacity
- New sales channels
In order to better understand what are the advantages of having an organized technology adoption mechanism, you need to see what are the costs of not having one. A rushed, or uneducated decision can influence the project negatively. You can find a good example by reading this article about MongoDB not being the right choice in this case that Sarah Mei exposes.
While diversity sounds good, a fragmented ecosystem can also mean:
- A disconnect between colleagues
- Longer response times to incoming projects
What does the stack at Graffino look like?
In order to easily communicate the tech stack, we’ve adopted the tech radar.
The tech radar is a tool to inspire and support engineering teams at Graffino to pick the best technologies for new projects; it provides a platform to share knowledge and experience in technologies, reflect on technology decisions, and continuously evolve our technology landscape. Based on the pioneering work of ThoughtWorks and the open-source contributions of Zalando, our tech radar sets out the changes in technologies that are interesting in software development — changes that we think our engineering teams should pay attention to and consider using in their projects.
The Graffino tech radar is a list of technologies, complemented by an assessment result, called ring assignment. We use four rings with the following semantics:
- ADOPT — Technologies we have high confidence in to serve our purpose, also on a large scale. Technologies with a usage culture in our Graffino production environment, are low risk and recommended to be widely used.
- TRIAL — Technologies that we have seen work with success in project work to solve a real problem; first serious usage experience that confirms benefits and can uncover limitations. TRIAL technologies are slightly riskier; some engineers in our organization walked this path and will share knowledge and experiences.
- ASSESS — Technologies that are promising and have clear potential value-add for us; technologies worth investing some research and prototyping efforts in to see if it has an impact. ASSESS technologies have higher risks; they are often brand new and highly unproven in our organization. You will find some engineers that have knowledge of the technology and promote it, you may even find teams that have started a prototyping effort.
- HOLD — Technologies not recommended to be used for new projects. Technologies that we think are not (yet) worth (further) investing in. HOLD technologies should not be used for new projects, but usually can be continued for existing projects.
Our main web stack currently consists of PHP and Laravel alongside Node.js on the backend and JavaScript with Vue and React on the frontend.
Conclusion
A tech stack will naturally emerge in a technical organization as people will look around for instruments to solve their challenges. This doesn’t mean you should observe idle as it happens. Taking ownership of the process can result in happier teammates and better business.
