How I Deal with “The New Technology” syndrom


Did this situation ever happen to you?

Customer / Product Owner / Manager / Fellow Developer comes to you with an article about “The New Best Thing” that “Solves All Problems that You Never Knew You Had” and praises that technology until you are forced to take it into account for the current or future projects.

I found in such situations that the praised technology is seldom useful. I never trust marketing materials published by the creator of that technology – be it a large company, a small company or an open source project. I never trust the fans of that technology. I don’t trust myself (at least I try not to, since I want to be an skeptical empiricist). The only thing I trust is tangible proof.

In the case of a new technology, the tangible proof is a working prototype of a key part of the project, ideally the one that is more likely to be difficult to implement with the new technology. The evaluation should take into account not only the development part, but also the testability, performance, security etc. Also, an important question to ask is “What can go wrong with this technology?”. And the most important thing to remember is that the burden of proof is on the advocates of the new technology, not on the people that are successfully using an old one.

It sounds easy enough, but at least my experience shows that it’s hard, for a number of reasons:

  • Many programmers develop in time a high tolerance to pain. After a while, some of them are willing to accept anything just because it’s different – not necessarily because it’s better
  • Many people fall prey to the marketing buzz. Fortunately, I’ve discovered an easy way to deal with this problem and I will teach it to you in the end of this article
  • In developer teams, critique is many times not focused on facts but on preferences or habits. (“I like using tabs for indentation” vs. “I like using spaces for indentation” is an extreme example)
  • If you play with a new toy, you fall in love with it. That’s why, I like to treat the new technology not as a toy but as a tool. Even if it proves to be good, I force it more and more until I find its limitations. That’s when I can say whether it’s useful or not.

There are probably other things to take into account, both psychological and technical, but I think that’s a good start.

Before I end this post, here’s the trick I use for reading marketing materials: I mentally replace each buzzword with the word “buzz”, which beside creating funny sentences also helps finding the real meaning of the phrase. Let’s see some examples:

From Microsoft Windows Azure whitepapers and website:

“The Windows Azure platform is poised to radically change the way Microsoft architects and developers think about building and managing applications.” = “The buzz is buzz to buzz the way buzz think about building and buzz applications”

“Windows Azure AppFabric provides a comprehensive cloud middleware platform for developing, deploying and managing applications on the Windows Azure Platform. ” = “Buzz buzz provides a buzz for developing, deploying and buzz applications on the buzz”

From IBM website:

“Use comprehensive query and reporting to make smarter decisions” = “Use buzz query and reporting to make buzz decisions”

“Seamless and intuitive integration into the Microsoft Desktop and common office applications including email, collaboration and web applications is essential for any ECM solution.” = “Buzz and buzz integration into the Microsoft Desktop and buzz applications including email, buzz and web applications is buzz for any ECM solution”

From Oracle website:

“It provides comprehensive features to easily manage the most demanding transaction processing, business intelligence, and content management applications.” = “It provides buzz features to buzz buzz the most buzz buzz buzz, buzz, and buzz”

“Protects from server failure, site failure, human error, and reduces planned downtime” = “Protects from buzz failure, buzz error, and reduces planned downtime”

As you can see, this is not a scientific method, but more of a mental helper in searching for the essential. Also, you decide what words you think are buzzwords – I just provided my own examples. I don’t advise anyone to use this method as a way of evaluation for a technology (that’s what the whole post before that was for). However, I find it very useful to identify the essential, useful, “hard” information when reading marketing materials. I hope you’ll find it helpful as well.

1 comment Reflections on design, craft and software

A new home for merging ideas about design

It is my strong belief that software design can learn a lot from other design disciplines. I wrote blog posts, a book and did talks on this topic, and it was time to group them all together. These ideas have now a new home: My plan is to add more blog posts there, and to involve other people doing work in this area.

Read My Book “Usable Software Design”

How UX techniques can be applied to software design to develop software better (given that the developer is the user of software design).

Read My Book “Coderetreat Hosting And Facilitating”

Learn how to facilitate and host a coderetreat from two of the most experienced coderetreat facilitators.