Hype Driven Development: What’s the Alternative?

As developers, we have all seen it: a colleague, another development team, a competitor who is always using the latest, greatest technology.  They are pushing the industry envelope, using the newest development language and latest framework.  No sooner have they implemented it than they are off on the next great thing.  Sometimes it seems like they spend more time upgrading than developing.  This, my fellow developers, is called Hype Driven Development (HDD), but is it the right approach?

The Genesis of Hype

Hype begins with a legitimate problem, such as:

• A codebase that is underperforming, overly complex, difficult to maintain, or buggy
• A framework that is approaching end of life
• A new library that only works with the latest version

An honest desire to solve problems leads to a “let me do some quick googling,” a few “you gotta check this out,” and eventually a “how do we convince the team?”  Two days later, everyone’s ready to rewrite the entire codebase in a new framework.  But how did we go from solving a legitimate problem to an entire rewrite?  Do we need a rewrite?  Or even a new framework?

Avoiding Hype

So how do we solve problems without falling victim to hype?

Several years ago, I was asked to rewrite a very complex mobile app for a client.  The original app was performing poorly, written in pure jQuery using PhoneGap (seriously), and had a challenging user interface. Mobile development was immature and an assortment of frameworks were competing to gain market share.  With little first-hand experience on the leading frameworks and no clear-cut direction from the client, my team took a step back.  We took the time to do a mini evaluation for almost every framework we thought we could use.  After an initial effort to identify the leading candidates, we rated each framework on the following categories:

Support: We were looking for the vendor and community support needed to solve challenges with the framework. We evaluated the number of questions asked (and answered!) on StackOverflow as well as other boards and forums.  We also captured the number of updates to the framework as well as bug fixes and enhancements in an effort to understand the viability of the product.

Popularity: Here, we were attempting to identify the relative market share for the various options. We pulled the number of downloads over various timeframes and evaluated not just the raw numbers but whether they were increasing or decreasing over time.

Performance: Performance is more difficult to measure without setting up complex proofs-of-concept, so we again relied on boards and forums.

We created a scoring matrix to guide an informed decision.  Based on the scoring, requirements, and functionality of each framework, we created three potential technology stacks, illustrated in the “Recommendations” column below.  We discussed this with the client, made a decision, and began implementation.  The whole evaluation took less than a week, was grounded in fact, and largely avoided hype.

Conclusion: Take the Time to Research and Evaluate

I often think back to the success of that project and am reminded of the importance of the value of researching and evaluating new technologies and frameworks rather than simply embrace hype.  What technology addresses the pain points you currently have?  What technology will be around in five years?  Taking the time to see past the hype and analyze the options is critical to determining the right approach for your team and your project.

Kevin Able is a principal architect in RevGen’s Digital Enablement practice.  He is passionate about delivering practical solutions that drive value to his clients.

Noah Benedict leads RevGen’s Digital Enablement practice.  He is passionate about using technology to advance business and empower his clients to embrace new opportunities.