It’s not a bug, it’s a feature!, indeed, a catchphrase that I’ll be using from now on, but à la marketing!

As aforementioned, while writing this post, I came across a plethora of explanations and interpretations of this specific phrase. Here is what I’ve learned.

Not an ordinary sentence, but a maxim

What I quickly understood is that this is a popular maxim among coders. The Jargon File (great index!) defines the sentence as being commonly used to describe “a bug that has been documented”. Furthermore:

“To call something a feature sometimes means the author of the program did not consider the particular case […] A standard joke is that a bug can be turned into a feature simply by documenting it (then theoretically no one can complain about it because it’s in the manual), or even by simply declaring it to be good.”

Well, a bug can indeed become something desirable; that is the first thing I learned. This maxim actually expresses all the complexity of developers’ work, a code is not immaculate and certainly not static. It evolves, progresses, and can take different paths that had not been foreseen and documented before. That appears to be particularly true for agile development processes.

It’s not what you say, but how you say it

Ultimately, this post addresses the importance of communication between marketers and developers in the world of tech startups and digital marketing. It is my belief that marketers have to better grasp the way developers approach a problem and how a software product is built. Indeed, these funny things developers say is an invitation to understand them!

The Given-When-Then example

Apart from being the source of inspiration for this post, our developers at Indorse made me realise that coding helps organise one’s thoughts and communicate them more efficiently. I have been particularly keen to use the Given-When-Then formula when presenting my ideas to my team.

As a marketer, I had a bad habit of writing a lot and explaining some ideas in a storytelling way. The Given-When-Then way of presenting ideas definitely improved our communication when working on new user flow and/or user cases. For instance:

GIVEN that I want to communicate my “user case“ ideas more efficiently;

WHEN I start learning basic coding methods and start using Given-When-Then templates;

THEN I will be able to communicate more efficiently with my colleagues, regardless of their expertise or role.

I’m not yet there… but it’s something I have adopted and that I’m trying to use when presenting some tricky things to my teammates!