Opinion: You should be tech-agnostic in every development project

(Image Credit: iStockPhoto/themacx)

People are comfortable and passionate about what they know. If you grow up a football fan, for example, your human nature will push your kids toward football, not soccer.

The same thing applies to development teams when they are selecting a tech stack for a project. Naturally, Java teams push projects toward Java, and .Net Framework teams prefer .Net.

It makes sense: We gravitate toward familiar tech because it's the comfortable, low-risk route. When developers voice this preference, they do it for honest reasons. They are recommending the best and fastest way they know how to build something.

Tech teams at large organizations especially enjoy taking this approach, as staying consistent with a tech stack across the entire enterprise seemingly allows for stability, ease, and a deeper focus on security.

Downsides of familiarity

Some major drawbacks can come along with this safe and familiar method. By sticking with what you know, you're likely limiting your project before you’ve even begun.

The problem you’re trying to solve should dictate the technology you use to solve it, not the other way around. When you try to fit the problem inside a predetermined technology stack, you’re likely ignoring the most efficient or sensible approach. You’re also choosing a solution with your team in mind, rather than thinking about the actual people for whom you’re solving the problem in the first place.

Take the increasing popularity of hybrid mobile apps using frameworks like PhoneGap, for example, and how they seem to promise codebase simplicity, faster development cycles, less financial investment, and happier executives. All too often, thinking of cost and speed, companies preselect the hybrid option before they ever know what their users actually want and need.

Then, if the end product misses the mark, it ends up costing the company dearly — both financially and in reputation. Once that happens, buyer’s remorse sets in, and the cascading effect can be quite brutal for enterprises. Executives begin pointing fingers, and the people in charge of execution may end up looking for new jobs.

Perks of a tech-agnostic approach

The best way to keep the user at the center of your decision-making is by taking a “technology-agnostic” approach to your projects. That means avoiding a one-size-fits-all mentality and keeping an open mind as you evaluate technologies.

The convenient or familiar route to market may seem like a time or money saver now, but if users hate the experience, then they won’t use the product, and you’ll be back at square one. Even if building something the "right way" is more expensive in the short term, building the wrong thing certainly costs more in the long run. In other words, the most expensive technology you’ll ever buy is the wrong technology.

Take LinkedIn’s mobile app, for example. Executives wanted to capitalize on the benefits of the hybrid mobile web-based approach but didn’t adequately consider how consumers were going to use their app. The result: They had to scrap the hybrid approach and go back to native.

By freeing yourself from a predetermined tech stack, you place a higher focus on users and solving their problems. You immediately become more understanding, more nuanced, and you can make smarter decisions — both technically and financially — that actually build products that change the user’s life for the better.

The biggest benefit of a tech-agnostic approach is that it will allow you to make the right decision. You can objectively evaluate the problem and pick the proper technology for the solution, rather than trying to squeeze the problem into your predetermined confines.

From developer to user, a tech-agnostic approach benefits everyone involved in your product.

Do you think a tech-agnostic approach is always beneficial? Share your thoughts in the comments.

Related Stories

Leave a comment


This will only be used to quickly provide signup information and will not allow us to post to your account or appear on your timeline.

15 Feb 2016, 2:23 p.m.

I first installed VB3 in 1995 from 20 floppy disks. I never learned it, too hard to teach myself. I eventually taught myself VB6 via scripting in classic ASP. In my first .Net job, I learned VB.Net, which was great because I already knew VB6 somewhat. When I was comfortable with that, we started using C# on another projects. So I was using both. As I used C# more, I forgot more of the VB (which really wasn't a big loss), but the transition was rough as it was vastly different in many ways. And then, when I worked on the VB.Net project, I kept adding curly braces and had to keep looking up VB syntax for simple stuff. Using web applications instead of websites got me out of the habit of inline coding in HTML. Now I have to learn MVC and go back to the inline type coding and I'm having trouble understanding it. Point is, being tech-stack agnostic is great if the programmers involved have the ability to learn new tech quickly and be good at it, but also switch gears and work in another tech. That's a smaller percentage than those that can learn new tech quickly and suck at it, but deliver a useable product. Then there are those of us who are old, take forever to learn next week's new tech and are honestly tired of learning new things to stay relevant. I sometimes envy the COBOL developers here (yes, they still exist). That tech hasn't changed in 30 years.