Update from December 2023: Three years after writing this not-so-fortunate post, I deeply regret the title I gave it in the first place (The three most misused terms in software development and how to deal with them), which follows a clickbait pattern so sadly common in the present days. A mix of getting caught in the wave and an absurd thirst for popularity? Probably.
The content was never good, but at least there is an idea somehow worth behind it. I've edited the title to something less crappy. Apologies.
The original content starts here:
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
Bad naming hurts communication, and communication is a first-class citizen in an activity like software development. Here we will be discussing the three most common -in my personal ranking, although they should appear for a fact in any top ten- wrongly used terms in the development jargon.
Service
This is the absolute winner of the most overloaded term in software development. It covers a range that goes from massive external applications, Facebook as a whole can be an authentication service, to virtually any class in a codebase, when in the context of a service container.
The multiple meanings the word service has are not bad per se. It is a broad term and that's necessary in a world that is that much into abstractions. However, this generality could mean a serious penalty to communication quality if not used in an agreed and seamlessly understood context.
One real personal experience: I spent half an hour totally disoriented in a meeting "to discuss services dependencies" until I realized the services were not the "microservices" I thought, in the context of software architecture, but the relations between "doctor services" in the context of medical activity, like blood analysis, dental surgery, and the like. By the time I got it was too late to catch up.
In several situations there is a better word than service, or it can be expressed together with another word that narrows the meaning to common ground. When we cannot find an alternative, better to settle first what kind of services are being discussed and do it again when the conversation jumps to another type.
Mock
In the context of testing, the broad usage of Mock means a replacement of a dependency of the code being tested to isolate this code from the dependency.
Actually, that's the definition of a test double and the term mock has overtaken its supertype in everyday talking.
Mocks are only one of the five types of test doubles, the most complex of all of them. They have a number of drawbacks and some benefits over other test doubles. I've written a full article dedicated to test doubles if you want to dig more into the differences.
The problem is that the indiscriminate use of mock for any kind of test double has created a trend of using them for every situation a double is needed and spreading the belief that they are the only tool available for such purpose. That's not true.
It is important to know as much as possible the tools at your disposal and chose the right one. Mocks have their use cases, use them when they fit, and other doubles when a mock is an overkill (which probably is most of the time by the way).
Refactor
Refactor is "the process of restructuring existing code —changing the factoring— without changing its external behavior" (wikipedia).
However, the common usage refers to "the process of writing code in a place where there was code before". It would be more economic and accurate to say "I am changing code", but we geeks like to sound sophisticated (I guess) and we prefer to wrongly use a word with some echoes of a sci-fi movie, losing the chance to communicate better in the process.
Not changing the external behavior of a piece of code means the same input will produce the same output. How you process this input and calculate this output is the implementation, and what you change when refactoring.
This has a strong link with (well written) tests: when refactoring you don't touch anything on the tests, just the code making them pass. Otherwise, you are changing, updating, expanding, rewriting... Don't use refactor when doing that and miss the opportunity to transmit a precise message of what you are actually doing.
But is it that bad?
It is. Every time we wrongly use one of these terms, or any other for the matter, we lose the opportunity to communicate better. This eventually translates to a waste of time, which is really bad.
At the same time, it would be a tough and pointless battle to try to eradicate them. Mostly because they are the right word to use in certain moments and contexts, and also because their adoption is too deep in the day to day life. However, we should develop the ability to detect when their usage is harming the communication and act accordingly, pointing it out or gently introducing accurate alternatives.
PS: I sincerely apologize for the slightly clickbait title :P
Top comments (2)
The situation with "Doctor Services" made my day! Thanks for this post, totally worth reading. :)
I don't know what kind of impression I made on the others, all the meeting smiling and no saying a word, but they still talk to me :D