Once upon a time, in the magic Startup Land, there was a fearful backend developer who needed to implement a new functionality.
He was working on a back office for movie producers to upload their movies. These movies could then be rented on a VOD platform. Did you hear about Netflix? Same spirit, except that a customer can rent each individual movies instead of paying a subscription.
After uploading their movies, the producers could choose in what country they would be available.
The new functionality was the following: producers could decide on a time-based availability in addition to the existing country-based availability. If a producer wanted his movie to be available only in May, he could do it with this new feature.
The management wanted a global time-based availability system which set the same availability for every country the movie was available. This was our immediate goal.
They later wanted to offer the possibility to set different availability periods for each country the movie was available in.
Of course, we had short deadlines.
The fearful developer began to implement the functionality. Let’s call him Knight Bob. The specification was clear, we had designs and mocks up for the new time-based availability interface. The producers could select some availability date ranges.
Then another developer, Wizard Hal, came to Knight Bob.
“Greetings Knight Bob! I see you began to implement the functionality. That’s great. However, we know for sure that after this functionality, we will need to develop another: the producer can choose different time-based availabilities for each country the movie is available.
What about implementing this feature on the backend, now? We would save some time. When we will have to develop this time-based availability by country, everything will be ready for the front end to implement the feature. No need to modify the backend again.
It’s simple: you have two tables in your database, time_availability and country_availability. You just need to link each availability to each country. It shouldn’t take too long.
Each time the producer choose a country, we link it to every time-based availabilities. Each time the producer create a time-based availability, we link them to each country. Easy peasy!”
At that time I was sitting between Knight Bob and Wizard Hal, so I heard the conversation. Without further ado I began to open my mouth:
“We don’t need this feature right now. Our task is to implement the time-based availabilities independently to the country-based one. I invoke the YAGNI principle!”
“But it’s so simple to just do that on the backend! Replied Wizard Hal. You just need to do that and this. It’s pretty straightforward.”
After days of development, Knight Bob noticed that on our frontend we ended up with two interfaces: one developed a while ago to choose the country the movie would be available and another new one to choose for what time period the movie would be available.
Since the time-based availability and the country-based availability was now tightly linked, we needed to merge the two interfaces without having any design. Otherwise, the frontend wasn’t really in phase with the backend for a very confusing experience for the end user.
Long story short: we had to undo everything. One week of development was lost.
How did that happen?
Re-read the conversations. Note the words used: “easy”, “simple”, “just”, “very”.
These words (part of the Lullaby Language) are the subjects of this article: try to notice them in day-to-day conversations, and you will understand they’re the cause of a lot of pain and suffering.
You want to know the true visage of one of the most hidden programmer’s demons? Come with me, let’s dive into the rabbit hole together.
Quick and dangerous conclusion
The devil is in the detail
The Lullaby Language mainly express how simple, easy and without effort the implementation of a functionality will be. It pops up often when specifications are discussed. They can be thrown randomly by managers or developers alike.
Using these words implies that all the thinking of a functionality has been done even if no developer thought seriously about it.
Who remember every detail of an application without looking at it? Nobody. Who think they remember everything? A lot of developers. How many times they are proven wrong? Too many.
Web development can be quickly complex. Stating that a functionality is “just” “easy” too fast is forgetting that every detail can have a great importance.
That’s why developers are often surprised when they begin to read the code. Even when they are developing a functionality for days: developers think it’s easy till they change their mind.
Remember my little story above? Nobody has seen that two interfaces for two tightly linked features wouldn’t work anymore. We didn’t think about it properly, since we stated from the beginning that it was simple.
Do you need to think what to do when you do the dishes or when you simply walk? Me neither. This is easy.
Software development is rarely that easy.
Assumption to stack holder
When the stack holders hear these magic Lullaby Language words from their developers, they will naturally think that the features won’t take long. This is an equivalent of a random time estimate. A short one on top.
This can lead to misunderstanding. Trying to clarify every little doubts regarding the specifications is primordial ; stating that the specifications are simple will magically state that everything is clear, even if it’s not.
This can lead to time-consuming back and forth between wrong implementations and angry managers who don’t understand how a “simple” functionality takes that long.
Keep in mind as well that even if the specifications look simple, it can get very complicated when you start coding it. I compare that to a phenomenon called illusion of competence: when you read something you didn’t know, everything seems clear, you have the impress you know it. When it’s time to apply your new knowledge or to explain it, you don’t remember anything anymore.
Having the impress to understand and applying what you understood are two different things. Having the impress to understand the specifications after a short explanation and without thinking it through can be as well an illusion.
Stating that a functionality is “just”, “simple”, “straightforward”, “easy”, “not complex” from a developer is simply a wild guess a stack holder can take too seriously.
How to make developers feel like idiots
Who question simplicity?
We are in a specification meeting where developers and managers are discussing new features. Suddenly, Wizard Hal state that this functionality is easy and won’t take time.
Even if half of the developer team don’t understand everything and have questions, they might not ask them. Why?
Asking questions for something easy doesn’t make sense. It means that they can’t understand something which is easy to understand. They don’t want to be seen as idiots. Especially since Wizard Hal is well respected in the development team.
As stated above, clarifying every little shadow areas in the specification is very important. Wild guessing with inappropriate wording is dangerous.
The fun part is: these questions will often show to everybody who think that “it’s so simple” how wrong they are. For developers afraid to ask questions, here’s a good reason to go beyond their fears: it will show unclear points in the specification and it’s likely you will raise a problem nobody thought about.
It makes sense since no developer at that point thought seriously about the feature. Even though, another point of view can shake the ideas of easiness.
You want to shine in the eyes of your pair? Here’s your chance. Even if it’s not the case, it’s never bad to better understand the domain you’re working in by simply asking. It doesn’t cost anything.
The weight of experience
I noticed a pattern: more experience a developer has, more he will be tempted to use the Lullaby Language. It makes sense: when you did the same things a great amount of time, you begin to be used to do it. Again and again.
These tasks become easy.
Here’s the catch: some features can be a bit different from the precedent, even if it looks the same at first. It’s where one can quickly state that the functionality will be “easy” and “won’t take time”, overlooking important details.
It’s where shortcuts are taken, specifications are not properly read and mistakes are made.
Even worse: I saw a lot of experienced developers being very surprised when another developer doesn’t know something. They will most of the time throw a distinctive “You don’t know that?” in a surprised tone. They can add “It’s pretty basic”. You can replace “basic” with “simple”, “easy” and such, depending on how you like to praise your superior knowledge. Because you know, experience baby.
If you’re tempted to do that, ask yourself: why are you doing so? What the benefits? What the consequences?
The developer, who apparently doesn’t know, might feel embarrassed because apparently he should know. In short, he will feel like an idiot who doesn’t have some basic knowledge.
This is a good way to prevent your colleagues to ask questions. No, this is not a good thing.
We all have our distinctive knowledge. I would even argue that a developer team with each member having different skills and knowledge is very good for a company, which can benefit from a broad skill set, and for the developers themselves. They can learn from each other.
However, if you expect that everybody you consider “good” need to have your knowledge, you are limiting yourself a lot and you will limit the others as well.
What the benefits of this kind of attitude? I don’t see any.
Good words from manager
The Lullaby Language is not only used by developers. Managers love as well using them.
It looks easy
Manager can genuinely think that a feature is easy because it looks easy. Displaying aggregated data from a dozen SQL tables in a list with filter and pagination? Easy peasy, we have the data, we just have to display it. If the application display already a lot of lists, it should be easy to do one more.
Obviously a manager should always keep in mind that developers are the only one knowing what happens behind the scene. If the code is not scalable or if the schemas in the database need to be changed, it won’t be that simple anymore. I don’t even speak about performance issues.
Again, even if the developers coded everything, they will often need to look at the code to know if a functionality will be easy to implement in a short amount of time.
It’s simple: do it quickly. Now.
Another bad habit managers can have:
- Assuming that a functionality is easy to implement.
- Interrupt a developer in his task for him to implement the super easy feature.
What are the consequences?
- It will slow down everything: the developer will have to switch from one task to another. Switching takes time and mental energy.
- An easy task with a lower priority can be imposed to a developer who does something which has a higher priority. It’s so easy, it won’t really affect the highest priority task, right? Since it’s simple, it will be fast to implement, right? I hope you get the sarcasm.
- Again the manager will gloss over the details if the task is very quickly declared as “easy”.
- The developer, the manager and the stake holder will be quickly annoyed if the task is everything but easy. From my experience it happens quite often.
What can you do?
Criticism is easy, and art is difficult. Here some advice to avoid the consequences of the Lullaby Language.
Ask for clarification
Remember my example at the beginning of this article? Even if I quickly criticized the fact that Wizard Hal wanted to implement something which was not necessary at that moment, I didn’t really try to avoid wasting time.
If somebody look over confident to say, about anything development related, that it will be easy, simple and just fast, you need to ask questions. Try to find if this person, manager or developer, can answer them. If he can’t, it means that he didn’t think through everything. This, at least, can show to everybody the (potential) hidden complexity.
Try to clarify everything as much as you can. This is really important in every situation, but even more when the Lullaby Language is used. Even if everything looks obvious. Even if everybody looks like they think it’s a waste of time to answer your questions. If a lot of details are forgotten, the time wasted during development can be way worse.
Generalities and misunderstanding about a functionality need to be clarified as well. Try to think about the whole functionality: do we need a new interface on the frontend for it? Do we need to modify the database? Will it work with the features already available?
You might think that you need a lot of experience to ask the good questions. Here’s a secret: there are no bad questions. A simple question can bring a lot of new elements to a conversation. Don’t be afraid to look like an idiot and ask them. At the end of the day, you might save hours of useless coding.
I always try to remember this: nobody really agrees on the definition of intelligence. If some people think you are dumb because you ask too many questions, they don’t really know what they are speaking about.
Personally I try to ask a lot of them. As far as I know, nobody ever thought that I was dumb because of that.
What questions to ask?
Here are the questions I usually ask when somebody brings some Lullaby Language in the conversation:
1 - Why do you think it’s that simple?
This will force your interlocutor to details his idea. At that point, bring all the knowledge you have about the application and ask questions about any shadowy area in your colleague’s reasoning.
Some examples:
- Did you think about …? Could it be a problem?
- Are you sure it’s that simple? What if…?
2 - I don’t really understand. What do you mean?
I ask this question when I don’t understand something (obviously) or when I think the explanation is not detailed enough.
This is an important point.
Without details, you can misunderstand everything, implement your misunderstanding, lose time and get frustrated. It’s worse than not understanding anything at all: if you don’t understand, you ask questions to clarify before implementing something wrong. If you think you understand but you miss some details, you implement wrong things and everybody is unhappy.
It will force the speaker to rephrase and going more into the details. These can improve your understanding drastically. It can help your other colleagues (who are part of the conversation) to avoid any misunderstandings as well.
3 - Should we wait to implement the functionality before claiming it’s easy?
I love this one. It emphasis a fact everybody should know: it’s difficult to judge the simplicity of a task before doing it. Especially when we speak about software development.
It doesn’t mean that you can’t give some deadlines to stack holders and managers. Actually, in a perfect world, it should not be necessary, but most of the time they will ask them up front. You can give approximations. Rough ones. Nothing which should be considered as the Eternal and Infinite Truth.
Again: the specific, the detail is always the pain point. Don’t underestimate it.
Questions and explanations are the solution
From my experience, the Lullaby Language is often used by everybody. It can be tiring to always precise in conversations that this language can bring a lot of wrong assumptions and misunderstanding with a false sens of security.
Not saying anything can lead to days of work wasted. Misunderstanding should be something developers strive to avoid, its cost will be always greater than defining correctly specifications and tasks upfront without quick and senseless judgements.
You can’t see every implementation details before doing it, of course. That’s all the point: don’t judge an implementation too quickly.
At the end it’s simple to ask questions and ultimately to show to everybody that even if a task looks easy, it’s often not as easy as we all think.