(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.