hype Driven Development

In the software development world, teams often make decisions about architecture or technology based on vague opinions, social media, or what is currently considered "hot." This is not a productive approach to software development. Instead, teams should choose the path of "solid software engineering," which is based on research and a serious consideration of the impact of technology choices on projects.

New Technologies- A New Hope

How many times has this happened? A team is searching for the right technology for their project. Somebody reads a blog article, something is trending on Twitter, or they come back from a conference where they had a great conversation about a new, amazing framework. Soon enough, the team starts using this new, shiny technology - or a software architecture design paradigm - whatever it may be. But instead of making the team faster and developing a better product like it was promised, the team falls behind. Everyone gets slower, becomes demotivated, and has trouble delivering the next working version of the software. Sometimes a huge pile of bugs needs to be fixed before anyone can even think about new functionality. They just need "a few more days" until everything is running smoothly with this new thing.

Hype

Hype Driven Development can take many different forms and touch projects in many different ways.

Reddit-Driven Development is a term used to describe the practice of making technology, architecture, or design decisions based on what a popular blogger has written, or what is currently trending on Reddit, Hackernews, blogs, Twitter, Facebook, GitHub, or other social media platforms.
Conference-Driven Development: Coming back from a conference or meetup is always exciting. Everyone is incredibly inspired! But beware, if you immediately adopt the latest hot lib/framework/architecture paradigm without doing your research first, it could turn out to be a major mistake. You could end up jumping like a tiger and landing like a doormat.Loudest-Shouting Driven Development: Somebody on the team won't stop talking about this one great technology. They just won't stop. The team gives in and decides to try it out.
Gem/lib/plugin Driven Development is a popular approach among the Ruby On Rails community. The basic idea is that any problem in Rails can be solved with a Gem. Sometimes a few lines of code would do the trick, but instead, people often prefer to throw lots of libs, plugins, gems, or frameworks at the problem until it eventually works.Stack Overflow Driven Development: when the developer gets the right solutions from stack Overflow- or copies and paste without really understanding it.

Teams Seal Their Own Fate

The problem with too much hype is that it can easily lead to bad decision-making. Both poor decisions around architecture and incorrect choices for tech stacks can haunt a team for months or even years down the road. In the worst case scenario, this can result in the need for a "big rewrite."

It seems that social media is at the root of the problem, as new ideas spread faster than they can be tested. Much faster than people can understand their pros and cons.

The Anatomy of Hype

most hypes have the same structure

Step 1: Real Problems and Solutions

It all starts with a problem in a company. The software team decides that the solution to the problem lies beyond the current technology stack, process, or architecture. The company creates a new framework, library, or paradigm, and soon the problem is solved.

Step 2: Announcements, Buzz and Keywords

The team is excited to show the world their successful work. Soon, they will be writing blog articles and giving talks at conferences and meetups. The problem is often not trivial, so everyone is proud to present the impressive results of a non-trivial solution. People are excited about the new technology. The only problem is that not everyone who is excited can understand the exact problem and all the details of the solution. It was, after all, a non-trivial problem with a non-trivial solution. It takes more than a tweet, a chat, or a blog post to adequately describe it. With communication tools like social media, blog posts, and lightning talks at conferences, the message gets fuzzy along the way.

Step 3: Hype

Many developers get caught up in the hype surrounding new technology. They read blog posts and attend conferences, eager to be among the first to adopt the new tool or framework. But sometimes they make the decision to use the new technology without fully understanding how it can benefit their team. They may be disappointed when it doesn't solve any of their existing problems. However, if they take the time to learn about the new tool and how it can be used to improve their workflow, they may find that it is a valuable addition to their toolkit.

Step 4 : Disappointment

Although the new technology doesn't make the team's lives as much easier throughout the sprints as they had hoped, it does eventually lighten their workload in the long run. Instead of struggling with the old technology, they can spend time learning the new one and be more productive in the future. The team may be slower at first, but they will improve with time. Management just needs to be patient and trust that the team will catch on. Everyone will be happy in the end if they just give it a chance.

Step 5: Realization

Finally, the team conducts a retrospective and realizes which compromises they need to make for the new technology, and for which use cases the technology would actually be relevant. Everyone becomes wiser and will certainly not make such rash decisions again... until the next hype comes along.

Case Studies

Let's look at a few real-world examples of how the 5 steps of a hype cycle could play out.

Example 1 : React.js

Step 1:One-page apps like Facebook are so complicated, with so many state-changing events, that it can be difficult to keep track of everything and ensure that the app's actual status is consistent.

Step 2: Facebook is promoting a new paradigm with some beautiful buzzwords: "functional, virtual DOM, components." Wow!

Step 3:Now you might be hearing from your team, "Facebook has created the front-end framework of the future! Let's write everything in React from now on!"

Step 4:There is a lot of work all at once

Step 5: React is an excellent choice for one-page apps that need a lot of real-time notifications. However, it may not be necessary for simpler applications.

Example 2: Test Driven Development (TDD)

Step 1 : David Heinemeier Hansson, the developer of the Ruby on Rails framework, recognizes that it can be difficult to TDD with Rails because the framework lacks an architecture that supports good object-oriented programming. He makes a pragmatic decision: not to write tests in advance.
Step 2:It all starts with a blog post and a talk. Formulated succinctly with "TDD is dead. Long live testing."
Step 3: As a team, we need to talk about this. "Let's get rid of tests! Our guru says so. We never do them anyway. Now we're at least being honest. We're finally being truthful."
Step 4:Oopss now it works less than before
Step 5: "TDD is neither dead nor alive. TDD is subject to compromises, including the risk of API changes, the skills of the person performing it, and the existing design" - Kent Beck

Example 3 : Microservices

Step 1 : Large monolithic applications are difficult to scale. There comes a point where we can break them up into individual services. This will make it easier to scale, both team-wide and in terms of requests per second.
Step 2:The buzzwords "scalability," "loose coupling," and "monolith" are flying around.
Step 3: Our team says: "Let's just write everything as services! We have such a huge ball of spaghetti code anyway because we have a monolithic architecture! Of course we need to rewrite everything as microservices!"
Step 4 :The team admits that development has become much slower since they switched to a microservices approach. It's difficult to deploy changes and they spend a lot of time tracking down errors on multiple systems
Step 5:However, they believe that microservices can be a worthwhile investment for scalability, provided the team has good DevOps skills and is willing to put in the effort. Before serious scalability issues arise, microservices may be an over-investment.

Example 4 : NoSQL

Step 1 :SQL databases have problems with high loads and unstructured data. So teams around the world are starting to develop a new type of database.
Step 2:Terms like "scalability, BigData, High Performance" are being thrown around everywhere:
Step 3:Our team says: "Our database is too slow and not big enough! We need NoSql!"
Step 4: After that, it says: "Do we really need to join tables? That's a no-go. Simple SQL operations are getting more and more difficult. Development is slow and our core problems remain unsolved."
Step 5: NoSql tools are designed to solve very specific problems - either extremely large data sets, unstructured data, or very high loads. SQL is actually a great tool and can handle high loads and large data sets well if used correctly.

Example 5: Elixir and Phoenix

Step 1: Web-Frameworks such as Ruby On Rails are not well suited for High Performance applications, distributed applications, and Websockets.
Step 2 :The words "scalability," "high performance," "distributed," and "fault-tolerant" are being used again.
Step 3:The team: "Oh my god, our application is slow and our chat is not scalable! No wonder nothing works!"
Step 4: The team, a little later: "Wow, learning Functional Programming and the Distributed Approach is not so easy. We are now very slow."
Step 5:Although Elixir and Phoenix are great frameworks, they require a significant amount of effort to learn. It is only worth it in the long run if you want to develop a particularly powerful app.

The list goes on and on. In the highly crowded IT space, there are many areas where such hypes are common. In the JavaScript world, new frameworks are born every day. Node.js (“Event Programming”), reactive programming, Meteor.js (“Shared State”), Front-end MVC, React.js. And what their names are. New architectures are also emerging in software development: Domain Driven Development, Hexagon, DCI. You can really draw from a wealth of buzzwords and hypes!

Good Practices

So if we can't rely on what others say and think online, how can we make wise decisions? Here are some good practices:

Test and research before you decide.

Spike - the favored technology doesn't learn from blogs, learn by doing (secured). Take a day or two to prototype functionality in the new technology before making the decision to switch everything. Let the team analyze the pros and cons.

Hackathons - a great way to increase a team's awareness of tradeoffs across technologies. Instead of just one person, have the whole team take some time out to try out all the interesting new technologies. This also gives you an idea of how these new changes work across the team

The Right Time

In principle, you can actually jump on the New Technology Hype Train at any time if you are really sure that the resources expended for the switch will pay off. Most technologies were developed to solve a specific problem. Is this specific problem actually present here? Is the problem big enough? Will the switch also save enough time? What happens if, after the switch, development speed slows down by a factor of two? Or four?

Different teams work at different speeds. Some teams take longer to complete tasks while others work more quickly. Quick teams can get bored with simple projects--these are also the types of teams that are more likely to introduce new technologies.

Of course, every team is different, but that's no excuse for not using spikes or hosting hackathons. If the team is having trouble delivering results, however, then caution is advised.

The Right People

A strong technical background is your friend - people who are familiar with different paradigms, understand theory (e.g. algorithms, concurrency, etc.) and have a good engineering culture tend to exaggerate less. Young developers are more easily carried away by the hype. But those who have seen a lot of technology over the years and often found themselves in trouble tend to get somewhat biased views on choosing the next technology. Knowledge and experience are the antidotes to hype.