Buzzwords are everywhere. Software engineering is full of them as well. By itself buzzwords are harmless, they are just labels, something known to many, shorthand to simplify and speedup communication. Problem arises when buzzwords are used to limit our thinking and choices.
I'm writing software for long time and noticed the negative effect of buzzwords many years ago. But recently I had an opportunity to observe drawbacks of "buzzword-based" thinking in its glory.
About a year ago I got a chance to be involved in projects as a "guest star": company (usually startup) invites me, I'm helping with design and implementation and then switching to another project. This is very interesting role, as I have chance to work on greenfield or early stage projects and leaving them far before they start to be boring. During last year there were 3 projects, all of them from different areas, with different domains and requirements. Nevertheless they share a lot of similarities - all of them are for online services, have mobile or Web UI, were of about the same size and at high level quite traditional (despite beliefs of their founders) Java/Kotlin backend + DB (MySQL or PostgreSQL).
Project #1
Engineers who were presenting their design to me when I was joining that project were very shy while telling me "For now app is just a monolith, but we're planning to switch to microservices in future". In fact, app was designed and implemented exactly as necessary. It's definitely not a something groundbreaking or award winning, but it don't need to be. It works now and will work just fine in foreseeable future without need to introduce microsevices. At present simplicity (and low price) to deploy and maintain for this startup is far more important than following bold buzzwords. Frankly, there were no need for me in this project, I had nothing to add, because from every standpoint things were done just right to the purpose. Once this app will grow to the point when actual splitup into microservices will be necessary, it can be easily done, since all boundaries are already built in into design.
Project #2
I've joined this project at the point when design was already done and significant part was already implemented. From the first sight it was obvious that initial (over-)design was done by very smart buzzword lovers. From very beginning it was designed as two microservices passing events back and forth between them. It had (unnecessarily) complex DB management (picked from Slack DB design) and (a number) of custom Spring annotations to make this stuff (somehow) manageable. And what is worse, engineers who designed this system were so proud of this design that they didn't wanted to even hear about any sensible change or even temporary simplification. As a consequence we were struggling with this piece of "beautiful engineering" for 10-12 hours every day. Complicated deployment, problems with debugging, hidden pitfalls of Spring "majic", painful (at best) navigation in the code - just to name few most annoying issues caused by buzzword-based initial design.
Project #3
By the time I've joined this project, it was in production for some time. At first look it was completely different. It is written in Kotlin, with a number of small frameworks for HTTP, dependency injection and DB interaction. Engineer who did an introduction was also very shy about lack of microservices, but very proud of use of Kotlin. Overall design is quite traditional and after some cleanups and refactorings works quite well despite sensible load. This project did show another buzzword-related issue. The use of Kotlin enabled a lot of freedom in code organization and this freedom was used in its full power to create complete mess internally. It took sensible time and efforts to make code look and work consistently across whole implemented functionality.
I'm far from blaming any buzzwords by themselves. They are just, well, buzzwords. The problem not in their existence. Problem is that many software engineers taking them as a rule of thumb or, at the bare minimum, recognize buzzwords as a the only right way to go. So, even not following this way is feeling like committing sins. Any technology or design approach is just a tool, not religion...
Top comments (0)