Hype Driven Development — How teams can avoid this

Hype Driven Development — How teams can avoid this

Introduction

Let’s imagine for a bit that you are in a development team doing software products or services, you have a very rock-solid planned platform, the team is doing well with the tools provided for your product specs, everything seems to be fine with the world.

One day, surfing the net, you notice that a new tool is released and is well received by the open source / framework community and, dare I say, is praised by everyone. Amazed by this, you read the documentation to learn how to use it, you tested it and, by the end of the day, you fall in love with this. Since your love for this new shiny tool is quite strong, you search a way or another to implement it in your project. You talk with your managers and leads about this and you convince them to use it. At the end of the month, the tool is implemented in your product and for now everything seems to be working.

Some time later, the team started to add more features on top of the tool that you suggested but you noticed a struggle in your team to have the features implemented, more bugs than before, taking more time to develop a feature, lots of “hacks” to get things done with the tool and etc. After some chitchat with your team and the leads, you come to the conclusion that adding this tool was not the best decision since it started to hurt the development cycle and, somehow, started to hurt the business. You and the team remove this tool and you have a lesson learned.

After reading this story… does it feel quite familiar to you? This topic is something what I like to call Hype Driven Development.

What is Hype Driven Development (HDD)?

I like to call it like this when you try to push a new tool / framework and then make decisions in your development team of including it without thinking of tradeoffs, technical debt, development and business implications.

Why is it harmful in development teams?

If you read the introduction, you may noticed a couple of problems that HDD can introduce to your teams but I want to be more explicit on this.

One of the problems that HDD causes in your team is a decrease in the speed of your development teams. The reason behind this is that your team needs time to understand the new introduced tool and how to use it in the project and that learning curve can cause some delays when delivering a new feature (sometimes this may no apply) but on top of that, when the tool it’s fully implemented in the product, it may take time for all the devs how to build a feature on top of this and if it was a bad decision, your team will struggle more on that.

A bad decision cause by HDD can cause you more problems that solutions. Instead of going smoothly you may have more bugs introduced in your system and more delicate parts that will require your attention.

A bad decision caused by HDD can cause a waste of time. Sounds harsh but it’s the truth. If a decision wasn’t made in a smart way, you will waste time implementing it, maintaining it but also removing it.

How can I avoid this in my team?

In the company I work, I’m leading a team where we are building an internal product / platform and we faced this kind of behaviour in the team. I’ll tell you a couple of techniques that helped me to understand better the hype from the devs and probably avoid it (or fell for it).

Ask for info and if it’s not enough ask again

This one is the most useful to me. Always try to ask for why, how and what… Why is it important for the business? why would it be useful for the team? why do you think it provides value? how much is gonna impact the team to implement this? what are the implications of use this?

Try to always look for the answer that will make more sense for the team and the business that actually provide a useful benefit. Don’t fall in answers like “F*ck it, let’s do it”, “this might be useful in the future”, “let’s implement it and see what happens”. Try to prove that the hype is worth it by doing a small PoC and see how it works, never ever try to use a new tool without knowing possible results.

Gather Feedback

Don’t listen to one person only. Try to be informed and try to understand, as much as possible, the hype of this. Maybe from other colleagues, the internet, Reddit, stack overflow, GitHub… You won’t know if the proposed tool will really add value to your business if you don’t listen to other people.

Software Design Decisions made by the team must not be taken lightly

One of the main focuses of your software design / architecture should be the ability to adapt to the change. However, when it comes on changes, I believe it must be an informed one and should taken with care. You and the team must be extremely cautious when you decide when to use a tool / framework in your platform since, again, will potentially impact the way everyone works, the and (possibly) how the business works; and how I mention mentioned before, a PoC will help you to understand all the possible implications of using a new tool. The usage of a tool / framework in conditions where is not the right one is absolutely worse than not having it.

Conclusions

At the end, i’m not trying to encourage you to be afraid of changes. Every software engineer must embrace changes. I’m encouraging you to be more informed and cautious when it comes to this.

Every time that you will use a new tool / framework, always think if it’s going to provide value to the team, the client, the product, the business, productivity, etc. Try to make smarter decisions and don’t fall in the hype, you may regret it later.

If you really liked this post, consider doing a small donation to buy me a coffee. I love coffee! 🙂 ☕ https://www.buymeacoffee.com/fern