Don’t Blindly Commit to a Technology Stack

At one time or another, we’ve all railed against the tech stack choice used by our organization to deliver a software application. But once we get in the driver’s seat on choosing what to use, it’s not that easy of a decision.

Between the ascent of .NET Core projects and the persistence of Java, evangelism for frameworks and other stack foundations seems at an all-time high.

The truth is that the best technology stack is the one that serves your company’s needs at the given moment. Perhaps Ruby on Rails helped your company build a platform that made it what it is. But today you may need the flexibility and control afforded by C# to meet your current goals.

Maybe everyone steers you toward Java, but you need Mono to work with your client’s preferred database system.

The bottom line is that your needs should drive your decisions. But people often get blinded by past experiences, hype and even convincing marketing pitches.

Take the time to evaluate the existing technology stack before making a commitment to something “new and improved”, even if it is your favorite. A visual, interactive road map of your current tech stack and the new suggestion helps the entire team understand your company’s technologies. If someone on the team proposes changes, ask tough questions. If you fail to ask enough questions before a major decision, anxiety is a given.

Zeal doesn’t replace good decision making. A person focused on a particular choice can bring a better option to your attention. Or they can send your software product team into a tailspin with deployment delays, integration issues and other headaches.

Software developers and project managers may debate on how “bad” they consider a particular tech stack. But it depends on what you need and what your choice can deliver.

As Scott Hanselman says, there are lots of ways to build tech stacks. Enthusiasm and skills don’t necessarily match the project’s needs. Your investment in a tech stack will change along with technology.

Answer these questions before deciding on what tech stack you’ll use or to determine if any change would be worthwhile:

  • What kind of application are you building?
  • Who is your user base?
  • How will they be using your app? Mobile? Desktop?
  • What tools are popular in your industry?
  • What does your engineering team know?
  • How difficult would it be to recruit team members experienced in the stack?
  • What is your timeline?

For more pointers on setting up your tech stack evaluation, read Seven Questions to Ask before Choosing Your Technology Stack, an article by Mike Hostetler of the Forbes Technology Council.

Sometimes no change is best. Sticking with the existing tech stack can reduce the work to launch your product. What your team knows they don’t have to learn. A new framework or language might introduce delay into your project timeline.

But if you need to use a different tech stack, don’t go into it blind – check it out before proceeding.

  • Is it well-documented?
  • How active is its community?
  • How fast does it change?
  • Who backs it and what’s their record on supporting such technologies?
  • How tough is it to test?
  • How long will it take your software product team to learn it?
  • What are its dependencies?

Even before finding answers to these questions, you’d better figure out if a compelling need exists to use this new tech stack. If you need a different tech stack to develop your application, is this the right one? Be prepared to prove why this tech stack above all others works best in this situation.

Real life intrudes on making these kinds of decisions. Despite best intentions and all the proof in the world, your organization may require you to stick with what you have. That might not be a matter of, “we’ve always done it this way,” which is the bane of progress everywhere. The cost of extending the timeline, inability to hire new developers experienced in the new tech stack and the problems changing would cause for your existing customers may make staying the course the right choice.

Izenda Chose Tech Stack for Integration with any Framework

This philosophy has governed our business model as well as our approach to our clients. We offer a way to integrate embedded BI, analytics and reporting into their application without regard to the framework they use. We help developers add instant value to their platforms. And we enable them to deliver features that keep their customers happy.

We developed our Izenda 7 Series using with a modern 3-tier embedded architecture. Its open front-end code base leverages the ReactJS framework, a modular .NET Web API, and a relational configuration database. Rapidly integrate self-service BI into Ruby, Python, Java, .NET, PHP and other modern web applications. Read more in our blog, Embed Analytics into any Application’s Tech Stack.

Other Resources

How to Choose Your Tech Stack by Gil Edelman of Silicon Valley Software Group

How to Choose the Right Tech Stack for Your App by Ben Lewis as posted on Cognizant QuickLeft

Leave a Reply