Developers love to talk a big game. At the Cave (thats what the developer room was called at Qualvu) It was not unusual to hear someone piss on the latest startup, saying how stupid this new “cool” app is or how trivial it is to code. This usually came about from a launch or an announcement of new funding that was on hacker news.
This trivialisation also happened within the company too, we always fantasised about working on some feature that was not approved and we would always try to convince the CTO by telling him that it would only take a short time to execute. Rarely did he ever fall for the bait, because the best way to convince him was to write code.
At Qualvu, we used to use this atrocious framework called Qcodo. Everyone hated it and developers day-dreamed about using something else. At the time (2011) I was experimenting with CakePHP to build a music site (Jekajo.com). CakePHP was supposed to be a Ruby on Rails like framework for PHP. It was supposed to be super simple to use… hence the name “Cake”. I loved it and was able to convince a co-worker to try it out. He loved it too and quickly we both were fantasising about how we could convince our company to switch.
After an afternoon of experimenting, Mark was able to make a small prototype of our company site that allowed us to query the database. We ran a few tests and CakePHP was significantly faster than Qcodo. We showed this to the CTO, we saw a lightbulb go off in his head. He asked some questions, we ran a few more tests and he was convinced. He started talking to us about a transition plan. Mark and I looked at each other, we were scared. Working in Qcodo was something we had moaned about for a while now and it landed on deaf ears.
It was scary how a few lines of code was more powerful than the eloquent speeches, arguments and mumbling we had previously done. We knew we would be in charge of the migration if this was to happen and it scared us… so we chickened out. We quickly convinced the CTO that this was a bad time to do this because we were in the middle of a rebranding phase, we were releasing some big features, blah blah blah and we closed the door on that chapter quicker than we opened it.
A year later we got a new employee, Andy, who did basically what we did. He didn’t even bother giving speeches on why we should change frameworks. We all kinda came to work one day and he had a prototype of our site working in Ruby on Rails. Unlike me he was brave in this situation, he owned the responsibility and basically made the company change from the atrocious Qcodo into something more modern.
I had a major takeaway from this experience. Its easy to talk, its easy to spew out theories, but it is equally as easy to counter them, which leads to no progress. If you have an idea that you need people to buy into, it is more effective to show them than to tell them.
Creating a working prototype is more powerful than giving speeches, writing papers and winning arguments, because when you put your code where your mouth is, it upgrades your theories into facts.
Editor’s Note: Adim is a software engineer and CEO of Blueport. This post first appeared on his blog.
