Technical Debt Scenario #4: Hype Driven Development
The development team is always on the hunt for the latest technology hype. Currently, there are more than two front-end frameworks used for the product and the time to launch new features is getting longer and longer. What would you do?
Let us examine the fourth scenario "Hype driven development" of how technical debt can cause.
If you are interested in the first, the second, and the third scenario how technical debt can cause click on the links below 👇
Patrick Roos
Patrick Roos
Patrick Roos
Table of contents:
Scenario
Developer 1: Do you know about this fancy new frontend framework XYZ on GitHub? 🤓
Developer 2: No...🤷♀️
Developer 1: What? 🤭 Wait, I'll send you the link.
Developer 1: Let us build that into our product. In my humble opinion this is a MUST -HAVE! We need this. Clean simple semantics, we can finally create components and I'm a contributor too. Have you seen it? 🤤
Developer 2: Hmm... I took a look at it. I think it is really proprietary... and probably it would be better to get rid of proprietary frameworks and develop against web standards, i.e. the web components. I'm not sure about that.🤔
Developer 1: Come on. You see that? With that, we can finally do BDD! 🚀
Developer 2: Well, probably we should introduce how to write clean unit tests first 🥴....but if you can not resist, why don't you propose it to our product team? I don't really care. 🥱
Developer 1: Yes, I'll propose it as a technical task. That would give us a cool side project for 1 - 3 months, I'm sure!!! 😎
What is the problem?
Constantly chasing the latest technology hype can slow down the pace of the entire development team because there are always more technologies to master. This also means that a technology zoo can accumulate. And with it, technology debt.
Technology should support to solve customer problems, not satisfy an individual's need for technological know-how. But that does not mean you should not use modern technologies.
Not only will the technology zoo get bigger, but the technology used will eventually become obsolete again. Using legacy technologies not only poses a risk to your product business but can have a massive impact on your attractiveness as an employer. This can cause lasting damage to the company.
A good example is the history of AngularJS and Angular. AngularJS became a real "hype". Many companies are moving their server-rendered web applications to the new front-end architectural style of "single-page applications" supported by the SPA framework AngularJS. After a few years, Google and the community decided to completely rewrite the framework to Angular. This move led to a lot of technical debt in many companies (until today!).
If you could turn back time, would you still rely on AngularJS and the SPA approach?
How can you prevent this problem?
Active technology management is an important activity you can undertake to get a handle on the technologies you use, and thus your current technical debt. Make this clear to your team and stakeholders. A good tool for active technology management is the technology radar.
What is a technology radar?
Use a technology radar to monitor all relevant technologies related to your business. The technology radar helps you identify technologies that you should assess, try, adopt or hold in your business. It tracks every applied technology in your company through its lifecycle. From a potentially identified - hyped - technology to a legacy technology that is being phased out.
How is the life cycle mapped in a technology radar?
The life cycle is represented by the Assess, Trial, Adopt, and Hold rings.
Assess
If a technology has potential for your business, such as the front-end framework from the scenario above, the team should probably include that technology in the Assess ring. That is, you should play around with that technology. For example, build a prototype for a particular application, get your hands dirty, and get some initial experience. At this stage, you can determine if this technology is just an "overrated" technology or if it really has the potential to solve or improve something. Then you can assess whether the company should try this particular technology in production.
Trial
If the experience from the Assess phase is really positive and there is a need for this technology in the company, the next phase is the 'trial' phase. In the trial phase, you use this particular technology in a low-risk environment. That is, a small side or auxiliary application of the business, but in production! By using the technology in a production application, you gain deeper experience. That is, you learn the true strengths and weaknesses of this technology. If the technology is used successfully for a few months and there is a need for wider use, the company may decide to adopt the technology.
Adopt
Adopt means that any application or product team in the company can use this technology. It can be used broadly.
Hold
With any technology, there comes an end of life at some point. When the technology is no longer supported by the community or the vendor, it is time to put the technology on hold. Putting on hold means that the technology should be decommissioned in all applications that use it. Ideally, this should be done in the short or medium term.
How are the technologies structured in a technology radar?
It depends on your business. One approach to how a technology radar can typically categorize technologies is the following (inspired by ThoughtWorks Technology Radar):
Techniques
Techniques supports you in the engineering process, e.g. Domain-Driven Design, Micro-Frontends
Tools
Tools are database management systems and engineering toolings, such as MongoDB, IntelliJ or k6
Platforms
Platforms are on which you build and develop applications, e.g. Azure DevOps, ArgoCD, Google Cloud Platform
Languages & Frameworks
Programming languages and frameworks, e.g. .NET, Java, TypeScript, React, Angular, Spring Boot
Should we use a technology radar company-wide or team-specific?
It depends on how you are organized.
If your teams have complete autonomy in technology decisions, they should use their own technology radar.
Often teams do not have this freedom of choice for various reasons.
That's why there are often overarching technology and architecture committees.
Technology Radar is a good tool for collaboration and communication when managing technology in such committees.
At what frequency should the technology radar be reassessed?
When working independently, the product team can schedule a technology day each month. In the day-to-day work, each team member can bring in new technologies that could solve particular problems. On technology day, you can re-evaluate all the items on the technology radar and discuss the new proposed technologies.
If the company operates with an architecture and technology committee, the committee can convene a technology day every quarter. An alternate member from each team comes to this committee and presents their new technology proposals. This workshop provides a space for technology discussion and sharing of expertise. The board decides whether a technology proposal will be included in the assess ring and how and who will evaluate it in the next period.
The same applies to the technologies in the other rings:
- Trial: How was the experience with technology X in the component Z?
- Adopt: Are there technologies which are going EoL or losing community support?
- Hold: What are the state of the migration path of the products which are using the hold technologies?
At what level should technology be placed on the technology radar?
From my perspective, only technologies with financial impact (implicit or explicit) or a lock-in risk should be put on the technology radar. Meaning:
- License cost
- Operating cost
- Big know-how building effort
- Tight coupling to the particular technology
The granularity of technologies you probably should not put on your technology radar:
Financially insignificant third-party dependencies, such as small Npm-Packages, Maven-Libraries or other libraries that can be easily replaced
Who can bring new technologies?
I suggest that every team member should have the opportunity to make suggestions for new technologies. This "openness" encourages discussion, but also helps prevent "hype-driven development".
Are there examples of good technology radars in practice?
I have summarized several examples on the following page:
Patrick Roos
How can I build a technology radar?
Thoughtworks provides an excel based tool to create an own technology radar:
Their "Build your Own Radar" logic is published as open-source.
thoughtworksZalando has also published their technology radar implementation.
zalandoThere is another open-source project to help you build your own technology radar:
bdarganSummary
Hype Driven Technology can be prevented by active technology management. Active technology management means continuously collecting technology suggestions in the actual problem areas, evaluating and trying out these technology suggestions, and clearly documenting the resulting technology decisions.
A good tool for technology management is to create and maintain a technology radar within the team or company-wide. The technology radar helps the team or the entire company document selected technologies and their current stage in the lifecycle. This monitoring can be used to define future actions, such as phasing out a legacy technology.
Comments ()