One of the first, and still one of the most well-known evangelists in the history of technology, is without any doubt Guy Kawasaki. In an article in the Harvard Business Review he explained his role and gave an interesting overview of what it is, its consequences and benefits. Written, of course, for the audience of HBR, which might not have much overlap with the audience of this humble publication you are reading right now.
The word, however, is still puzzling to no end. “Evangelizing.”A word of greek origin (thanks, Guy) that immediately brings us to the world of religions. The problem with such a word is that, after hearing it, a quick overview of the current state of the world (a savant mix of individualism, hysteria, extremism, and sectarism,) will prompt any sentient being with some remain of empathy to quickly retreat to a remote island in the Arctic, and wish for themselves to be forgotten forever.
And the truth is that, as Guy aptly mentions, in this age of social media, we are all evangelizers.
Actually, in a rather sad metaphysical conundrum, both Graham and the author of these lines are evangelizing you, our faithful readership, with our own opinions of the state of the industry. Who are we kidding?
Lies
We all know the difficult state of our industry. We are producing more software than ever; the working conditions of those making it are worsening; and the resulting quality of our work is dwingling and breaking havoc. Yet, we still fall for charmismatic speakers on stages, writing incredibly detailed blog posts, speaking clearly through their Yeti microphones and luring us into yet another wave of hyped technology.
After decades of blindly eating those words and falling into despair, a change is taking place. We do not simply take those words and swallow them without reflection. We have seen the terrible consequences of adopting technology just for the sake of beefing up a resumé. At least, this author wants to believe that those reading these words have asked themselves this questions, and that we fill our coffee mugs every morning with healthy, equal doses of caffeine and skepticism.
Honestization
Let us create a new word. After all, this is one of the greatest skills of our industry, the other being inventing acronyms. Instead of Evangelizing a new technology, in whichever medium you choose to do that, maybe we should be Honestizing them.
From a practical point of view, that would mean putting forward all the flaws and shortcomings first. Imagine reading a blog post about a new Node module that starts with the enumeration of all its drawbacks, incompatibilities, reduced scope of testing, limited range of applicability, and which would then (and only then) start explaining its benefits. This author would personally would welcome such an approach (not only for Node modules, that is, although given the pervasiveness of JavaScript in our industry it might be a great place to start.)
How would Honestization work? We could use something like an MPAA film rating for conference talks, blog posts, podcasts and other social media channels:
- G for introductory talks, mostly harmless pieces of information about team dynamics, project management methodologies, or being a developer at 40.
- PG for “Professional Guidance Suggested;” the contents of such talks might have unintended consequences if applied in sensitive environments, like production.
- PG-13 would mean “Professionals Strongly Cautioned,” where the “13” means years of experience in the branch. That means, stuff most developers should not care about or be able to apply in their jobs before reaching the very senior age of 35 years old.
- R for “Restricted;” heavy, dangerous advice not to be taken lightly, and only to be applied by white-bearded, senile professional staff, that is, above 40 years old.
- Finally, NC-17 for any tutorial or conference session about the C programming language, whichever its subject or applicability may be.
Of course the writer of these lines will not be holding its breath until this happens, for such a system will never see the day of light, just like there might never be a Hippocratic Oath for software developers.
There is, however, tremendous value in such a system.
Documenting not the benefits of a particular technology or idea, but rather of all its shortcomings. Leaving behind the positivity that is drowning us in lies, with “small print” level of warnings – when they exist at all, or behind a 35-page “License” that one has to “Agree” whenever downloading a piece of technology.
Making our industry more honest. Stating openly that things break. Making sure everybody agrees that things do not really work the way they are supposed to, except in some very specific environments and situations. Maybe those environments and situations can be reproduced easily, and thus the true value of a piece of software can unfold in front of us. But in those cases where this is not possible, just be upfront about it.
Do Not Lie To Me
It all boils down to the idea that making a better world with software means being sincere to one another. Avoid the lies. Do not be a hypocrite. Be upfront about the shortcomings of your software. Do not sell it as a solution for anything and everything, and do not shy away from saying what is wrong with your ideas.
Paraphrasing Joel Spolsky, know that whichever abstraction comes up in your mind, they will be leaky anyway. Acknowledging those leakages from the start might be the bowl of air our industry needs to start afresh.
