Making a case for a simplified tech-stack.

Recent ads for software developer position specified the following experience:

Required:

.NET framework, C#, ASP.NET, ADO.NET, Web Services, WPF or WCF, SQL Server (2005 or greater) and/or Oracle (9i or greater), Angular OR React, Active Directory, SSRS report development

Preferred:

MCSD, Node.js, AJAX, Telerik, MVC 2, Messaging, Java

And this one:

Technologies we use: Angular, React, React Native, Xamarin, Vue, and various JavaScript frameworks, C#, Java, .NET Core, Java Spring Boot, various Azure and AWS PaaS compute and hosting (App Services, AKS, EKS, serverless / Functions / Lambda, etc.), storage and messaging services like relational databases (SQL Server, Oracle, MySQL, etc.), no-SQL (Cosmos DB, DynamoDB, etc.), API Management, modern DevOps pipelines and infrastructure as code (Azure DevOps, Terraform, etc.)

If your software developer requirements look anything like this, you should consider whether your tech stack choices are helping or hindering your company.

Pros-n-Cons of Complex Tech-Stack

Pros

·  Features, features, features

·  Realistically deliver features beyond your teams’ capabilities

·  Framework

·  Provides focus for immediate forward progress by those familiar with the framework

·  Alphabet Soup of Bragging Rights

·  Fits “buy-rather-than-build” philosophy

·  External (purchased) support

Cons

·  Version lifecycle of each piece of Tech may require re-training personnel and/or software re-factoring/re-design

·  Focus and budget goes to tech-stack, starving roles like Business Rules, UI/UX, Graphics Design Artist

·  Needed functionality not provided by framework is deferred, or additional tech-stack components added

·  License requirements for each piece of tech

·  Frustration from increasingly complex tech-stack leads to higher payroll costs and turnover

·  Increasingly difficult to locate and then train replacement personnel or grow teams

·  Team members will typically be specialists, not generalists, requiring a larger staff and decreasing cross-training

·  Developer environment setup/maintenance overhead continues to grow

·  Trace/Debug across tech-stack is unwieldy, complicated, or impossible

·  Deployment becomes increasingly complex, and possibly costly

What I’m seeing

It used to be if we had a problem we’d “throw hardware at it”. Now, it seems that we just throw (often disparate) tech at it.

Every individual piece of tech we use has its own lifecycle, business model, target audience, and agenda. And those all change over time, often at the most inconvenient time.

This continuous, short-term thinking has a growing technical-debt* associated with it.

I’m seeing the highest turnover clustered around the most complex tech amalgam, and most stable personnel teams at the simpler tech stacks.

How did we get here?

I’m placing the blame for complex tech-stacks in these areas:

Job market instability

Increased job instability breeds fear in developers. Developers only defense is to stay relevant. Developers naturally push for using the latest tech, regardless of the needs of the company, for the sake of their resume. 

Appetite for new tech and buzz words by dev staff

Community peer pressure and struggle for relevance are driving forces to choose the latest tech. This could be the greatest contributor of anything-goes tech-wise, diametrically opposed to the looking-out-for-the-business-long-term point of view.

Appetite for new tech and buzz words by upper mgmt.; competitive market pressures.

Marketing and Management want the latest buzz words to throw around in brochures, web sites, and at cocktail parties. In the struggle for differentiation and dominance, it’s natural to want to capitalize on the buzz surrounding latest tech.

Promised Quick-implementation of features

Tech marketers make it sound so easy! Need feature X? Our tech will deliver that today!

(Micro)Service principles that advocate ease of mixing stacks, languages, and OS’s

Yes, Microservice and other Service Oriented Architecture makes it easy to mix stacks, languages, and operating systems. Unfortunately, just because you can, doesn’t mean you should. There certainly are times when this is desirable and advantageous**.  But it’s an easy trap to fall in and hard to get out of. Then it’s: “Well, what’s one more language or tech-stack…”

Responsibility falls to the CTO/CIO and the Architect

A Software Architects’ role includes choosing or recommending tech-stacks, languages, and OS’s. The analysis has to include tech trends, current tech, current and future business needs, dev personnel capabilities, cross-training, etc. Specific attention must be given to legacy maintenance, which lasts longer than anyone likes to admit. If there’s not enough budget to convert existing products to the new tech, then the company will be stuck with supporting developers for each tech-stack, or cross-train every existing and future dev. Typically, the cross-training is minimal, and specialists for one tech-stack are regularly called upon to modify code from another tech-stack, resulting in slow, messy maintenance and increasing technical-debt.

For Your Consideration

Engineering and Architecture are primarily about tradeoffs - balancing budget, features, and maintenance. Taking the quick-fix approach of adopting burgeoning tech-stacks is a pay-me-later trap (i.e. technical debt). For your business to last, you must be judicious about adopting additional tech, and you must be vigilant about phasing out old tech. 

Protect your budget so you can invest in BA, UI/UX, and Graphics Artistry that truly makes your software useful, profitable, and competitive in the long run.

Steps to achieve simplification

·        Standardize on a powerful, general-purpose language like Java or C#

·        Consolidate to the fewest possible external libraries.

·        Write your own specialized libraries, when possible

·        Phase out old or least-used tech

My current tech-stack

Flutter (front-end), C# .NET Core (back-end-as-a-service, hosted on AWS LightSail), MySQL RDS (hosted on AWS), persistent storage using AWS S3.

I can deploy either the front-end or the back-end in under 60 seconds without automation (though I love automation).

I can easily test locally, trace easily, and the architecture scales easily.

(*) Technical debt is any short-term fix or decision that will cost much more later to fix or refactor correctly.

(**) Certain specialized functionality IS much easier to deliver in a language that’s tailored for that functionality. The down-side is that the more a language is tailored, the harder it is to use that language for other (also necessary) things. I recommend using extreme caution when adding new languages to your mix, because of the reasons stated, above. Look for or build libraries in your current language, if at all possible. If you mix, don’t add business rules or other features that require ongoing maintenance / extending in the specialized language (i.e. use it for what it was tailored, and only for that).