Sam Sanders writes: “I would be interested in hearing how you prioritize and choose between the proliferation of technology stacks that keep popping up. Do you stick with tried-and-true, do you teach yourself on sample applications, or do you ever take on a client who requests the technology flavor of the month?”
That’s a great question! Thank you, Sam.
This is a topic I take very seriously and it is discussed at every new project start. As an independent technology architect, I have a responsibility to my clients – not just to deliver them a great software product, but to also give them a valuable asset which can be efficiently maintained and expanded throughout its lifetime.
In this post, I’ll focus on the technology stack as it relates to new software development.
Let me start by saying, I have an individual passion for learning new languages, platforms, and frameworks. I am on a continuous quest to improve development efficiencies and I enjoy examining the new approaches found in new technologies. I read, watch YouTube, and tinker with sample projects on my own time. By doing these things, I pick up which new techniques can be applied to older and more stable frameworks, and which new frameworks are interesting enough to consider using in future projects.
Armed with knowledge from my personal R&D, there are many factors which go into the decision of what to apply to new software development projects.
Learning New Languages
Good software developers are always learning something new and investigating new development options to stay relevant. Sometimes it is possible to expand skillsets on simple projects for a customer or situational requirement. A recent project required bridging an off-the-shelf Member Management Portal developed on top of SalesForce with an off-the-shelf SaaS reporting tool. The project was very small and had a longer lead time to implementation, so I used it as an opportunity to learned Apex (the language of SalesForce apps).
Around the same time, another customer needed us to extend the content personalization system available to them in HubSpot. This project was a bit bigger but it also included enough time to learn HubSpot’s language, HubL. These projects are beneficial because – like my personal R&D time – they allow Digital Mettle to expand our library of skills for larger projects.
The most important thing to remember as a software development company is to only accept projects in unfamiliar technologies if they are small enough in scope that there is no risk of failing the client. I never present myself or my team as experts in something that we are not.
What Technology Stack Is Your Customer Already Using
The second major factor in platform selection is frequently an unspoken client requirement – sticking with a technology stack that is familiar to their IT staff.
When I start new projects, especially for bigger organizations, I begin with the assumption that someday someone inside the company will need to perform ongoing maintenance on the software. We look at the types of systems the customer already has to determine the best tech stack choices for their project.
If that client has several existing custom systems on Windows with SQL Server and has three career .NET developers, I would be doing them a disservice to deliver them a new product built on Linux with MySQL. Anything that I can do from the project start to make my future successor’s life easier, I try to do.
Several years ago the roles were reversed. A company was downsizing and I was taking over from the internal team. I spent a few days with them for the handoff. Their solution was a complete mess. They had components in four different stacks across three different hosting environments with two different source controls systems and no continuous integration. Nothing about how to approach development or deployment was well-documented. Once I understood what I was dealing with, it still took almost a day to setup a development PC with all the prerequisites needed to work on it. At the time I remember promising myself that I would never leave a customer in that situation.
The next consideration in choosing the right technology stack is user experience. If the project is to create a general release product for the web, we are frequently driven toward the Single Page Application (SPA) approach to give the product an app-like feel.
If the project is to create an internal line-of-business web tool, we keep a multiple page approach which allows the development to be more modular with less upfront planning. We always have our eye on when the client will need a native desktop or mobile application, but the web is almost always the first requirement for us.
Timelines & Risk Tolerance
The next factors we evaluate are timelines and risk tolerance. If the project needs to go to production in a short timeline then we choose frameworks we already know well. New platforms normally come with benefits which are well advertised, but with “gotchas” that you only discover later.
If we have a customer who won’t understand if we say, “The delay is not our fault. It’s a problem in the platform.” then we have to choose a stack whose ‘gotchas’ we already know how to avoid. However, if we have a situation where we are free to try a new thing, that’s where the decisions become more difficult.
Again, my focus is on creating an asset which is of the highest possible value to my customer. There is a lot of thought that goes into choosing the right stack. The best reasons to consider something new are:
- future-proofing the solution
- developer efficiency (reducing costs)
The worst reason to consider something new is just because it is new.
Making the Choice for a New Framework
When considering a new framework, I research the companies backing it and their history with other technologies. I’m also very interested in how other major vendors are using the platform and if there is good cross-vendor adoption.
There are no guarantees in the tech world, but I want to give my projects the best chance for long-term support.
Example 2: The first SPA framework I tried was KnockoutJS, which I really liked. But Knockout’s author, Steve Sanderson, is a Microsoft employee and writes more Angular articles and tutorials than Knockout updates. Angular’s backing by Google and adoption by Microsoft including their commitment to Angular tools in Visual Studio has made Angular our SPA framework of choice, despite my personal preference for Knockout.
Choosing the right technology stack solution for clients is a complicated process. As a custom software developer, I need to constantly keep in mind that I need to:
- Always be learning new things for fun and/or in small low-risk projects to benefit my customers.
- Balance future-proofing a new project by using something new against the risks of not delivering on time.
- Consider what technologies can be maintained by the product owner.
- Take into consideration the vendors backing new technologies.
I hope that answered your question, Sam. If not, leave a comment and I’ll be glad to discuss further.