How to avoid picking the wrong technology just because it's cool
I&#x27;ve seen this in action. Using code generators to convert XML configuration to a few API end points. Or using a DSL&#x2F;rules engine because you don&#x27;t want to write code. Or having APIs that hit other APIs ad infinitum when the whole thing runs on one server because &quot;micro services are the only right way&quot;. The result was we spent time gluing  together what was already a monolith disguising as microservices, rather than adding features the customers wanted<p>More recently I had to solve time drift on 1000s of devices. The problem was someone installed puppet to manage those devices which uses NTP. The devices are behind firewalls so if they block the puppet master or mess with SSL puppet doesn&#x27;t even phone home. Or worse it gets incorrect time from NTP peers on the network. The solution was to throw out the shiny tool &quot;puppet&quot; and just call &quot;date&quot;. Puppet and NTP are great in theory for getting time down to the millisecond but totally backfired when some devices were off by over 24 hours. For our purposes as long as all devices were within 5 minutes we were good. The irony was after disabling NTP puppet just started it again. And we couldn&#x27;t use puppet to fix that since 50% of our users had it blocked. No other choice but to throw out puppet and start over from scratch. The guy who spent months setting up puppet was not happy.