Disclaimer: This is not a post to discourage your next new thing, in fact as developers and technology decisions makers, we all have our own perils and survival dependency in Buzz engineering. But it is good to understand things, since there is an increasing noise around high technology churn and failures.

So, what is Buzz Engineering – It is easy to spot buzz engineering but hard to digest.

• Aren’t you working on some next level microservices with serverless orchestration on containers?
• Aren’t you guys releasing at least once a week?
• Oops – are you still using relational databases?
• Why isn’t there any AI in your program – AI should have rendered that CSS better in IE. #lol
• You should be kidding me, you haven’t started that project in Rust and blockchain.
• Oh! Gosh, you take initial time to design – You’re waterfally Yack!! – my personal favorite

Yes, that exactly the Buzz Engineering is.

It’s not that, we shouldn’t use anything new: We SHOULD and INNOVATE, the innovation should be around the problem rather than on a technology buzz. The reasoning should come from the problem, rather than discovering a problem because you already got a hot technology in your hand.

The world’s real problems need far more complex and strong engineering and technology innovation along with the careful digestion of the problem. Understanding the existing problem context, the future, landscape change and continuous improvements on innovation are essential. Sometimes it is disappointing to see the buzz engineering overtaking the problem. Not all problems need the same formula and not all the problems can be solved with the same technology.

From a practical developer point of view, getting into technologies and implementations due someone else is doing it is quite common. In my opinion this is a killer of creative engineering. But at the same time, we all are both the victims and beneficiaries of buzz engineering.