u/HyperDanon — reddlx

This post hasn't been generated by LLM.

Our industry is being constantly flodded by buzzwords, hype, marketing and easy solutions. Believe it or not, but software engineering is really hard, when you think about it. Most great break-throughs didn't happen due to some technological advancment, but due to a mind-shift in certain approches. Othertimes, it's just replacing something we thought of being fundamental with something else. These appraoches tend to become popular, because they actually improve something. Someobody coins a cool-sounding name for it, and then it grows into popularity. HOWEVER. As it grows, more and more people unfamiliar with the concept and the context get hold of it, not really understand what it means, slightly twaek it to something simpler, not so different to what they're used to. Me, I'm no exception, I know I too am guilty of doing that. I would like to get better and not participate further in that, as well as warn fellow programmers of what I have found and how I am dealing with it. This is subjective, this is just how I chose to think about practices and buzzwords. I will say however, that I think it's better to follow complicated, though true ideas, rather than easy, false ones.

What is listed below is my opinion, it could be subjective.

Here are some of the buzzwords, I think I have learned are misleading:

"Agile is just scrum" - popular thing among less experienced developers is that "agile" is about jira, story points, tickets, tasks, sprints, retros, poker games, plannings, and all that crap. Obviously, that's not quite right. My current understanding is that "agile" essentially means to develop software in such a way that it's quick and easy, that you can change your direction without much hussle. Expect change, don't commit to quickly to one solution, validate your ideas. Eseentially agile is opposite of waterfall, at least that's according to my current understanding.
"TDD is just unit testing" - another mistake is believing that tdd is just about writing automated tests. Obviously that's not about that. My current understanding is that it's mainly about creating very well designed, testable code, with quick reaction to feedback. The code and the tests give you feedback about your design, because it just so happens that untestable code and badly design code are very aligned. In order to be test-driven, you need to write your code first.
"DevOps is docker and kubernetes" - devops has become a job description, sadly. When I looked into that, I found out that the main idea behind devops was that there was too much overhead when doing handoffs between development (dev) and operations/sysadmins (ops), there was poor communication, slow feedback, low bandwidth. So the whole idea behind devops, was to take these two camps: dev + ops and get devops; to unify these, so that there isn't that barrier anymore. But what did it end up with? That companies think that they need software developers and devops guys - they essentially reinvented operations/sysadmins. They introduced something the very idea behind devops wanted to reduce. Now, whether you join the two camps or keep them separate is up to you, but don't say you have devops when yuo have those two silos still in your structure.
"Microservices are just apps that talk http to ane another" - ughh. The idea behind them was to allow big teams to scale, but allowing certain modules in your applications to be independently releaseable from one another. That's it. You can do that, you have microservices, you don't and you don't. That means you can't really test them toghether, there need to be other solutions for checking releasability between them, most commonly contract tests. But people don't seem to get it for some reason? They think they can just have two apps that that tcp or http between each other and they have a microservice? What they've just done is introduce churn, work, latency and wasted time in points where they need to introduce changes.
Very bad thing, huge cost, almost never worth paying, unless you're netflix or google.
"CI is running build in github actions" - Obviously, it's not a fault of many people, because CI is a very popular term, and not a lot of people understand what it really means. In its origin, "continuous integraiton" essentially means to integrate our changes continuously. Integrate just means merge or rebase, join them, so that there aren't multiple versions of the system in multilpe places. Continuous Integration means there is only one valid version of the system - the current one. If you don't integrate your changes too frequently, then they diverge. You still need to integrate them, but if you're mergin your changes once every week or two, it's still integration, just not conitnuous integration. The whole idea is about continuously integring them, say every few hours up to a day. Rant time: now, people don't like doing that, they like working in feature branches, but word "CI" is also hyped, so they succumb to this idea that CI is just running build in the cloud. Now, granted, running build in github actions is useful, because it can determine whether the changes are properly integrated without anyone's developers machine, but it's just a supporting tooling, not the practice. It's the practice that counts.
"BDD is using feature files" - another good one. As far as I know, bdd was about test-driving the software from the perspective of the behaviour we're using it for. People, when testing, relied on technology too much: it's a web app, it's a spring app, it's a flutter app, it's a ruby on rails app, it's a mobile app, desktop app. Who cares? It's important what the application is doing. Developers are too close to the code so it's easy to mistake your project for being "a react native app", rather than a dating app, a tutoring app, a payroll app, a chat app, a game, etc. Bdd was about getting programmers to to write tests in terms what the application is for, now for how it's built. That was the idea behind inventing names "scenario", "rule", "example", "actor"; and ultimately about feature files, cucumber and gherkin. But these are just supporting tools. Even worse, some people put implementation details BACK into the feature files, completely defeating its purpose. How many times have you seen feature files that say something like "click a button", "fill this field", "wait for url change". If you are going to do that, you are doing exactly the same thing you could do with a regular test runner, because it's clearly not bdd what you're doing. On the other hand you can do BDD with junit or vitest if you so chose, just don't use any technical language and focus on the behaviour. Some people suspect that behaviour driving the app might even have something to do with the name "BDD" :o

I can go on, but I can notice there's a very simple pattern behind all of these:

Someone invents a practice, that's very efficient (agile, tdd, devops, microservice, ci, bdd)
Supporting tooling around it is built (jira, junit, docker/k8s/terra, http aps/contracts, github actions, feature file)
A lot of people learn about it, don't really understand the mindset
They mistake the buzzword is just about the tooling, not the practice
Buzzword loses it's original meaning, and is now a token of a tool, that doesn't deliver any value, because people adopting it only adopt the tool, not the mindset and practices.

How I try not to be fooled by these: When a new hyped buzzword appears, try not to listen to marketing and other peoples adopting it. Try to find where it originally came from. If I listen to what majority of programmers say, I will learn about the supporting tooling only; not about the mindset and practice. I need to learn what the original idea was, what problem it tried to address (there is always one), and what mindset-shift it proposes (there's always one too). Once you have that, supporting tools are as easy to land as as anything.