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
Top comments (1)
I think sometimes this is the symptom of a greater issue. Team members feel like they are not able to be productive for some reason: the new open-office layout which was supposed to enhance communication (and did you know our CEO sits in a cubicle too!?), endless meetings, reliance on legacy technologies they don't feel comfortable using but the architect has been recommending for ten years straight, etc.
One night you find something that promises to make you productive again and you're so burnt out and frustrated you are willing to give it a try. Maybe just the free trial. Screw it, I'll buy myself a license and when it catches on I can get reimbursed.
If everyone feels like they are being used to the best of their unique abilities and talents on a project, everyone should be feeling productive. When that is not the case, when no real work occurs between the hours of 9AM and 5PM, there are serious issues that need to be worked out.