There isn’t necessarily just one tool for the job
My dad went from the US Navy to IBM. Basically, he was in the military for his whole career. He had no glamorous job, he was a field engineer. While he repaired some of the bigger machines, he mostly specialized in peripherals; scanners, disk/tape drives and industrial speed printers. He carried around an amazing set of tools courtesy of IBM. Dad also liked to tinker with mechanical devices and woodworking in his free time. He had a humongous array of tools between his IBM gear and the Sears Craftsman tools he purchased with his own money.
I frequently got drafted into helping him with house projects – mechanical, electrical, plumbing and woodworking – the whole enchilada. Those of you that know me know that I am not handy. I fix most things using two tools; the pen and the checkbook. I tried Pa’s patience on more than one occasion. He had a ton of pithy little sayings that he’d offer while we were working on something. Using the “right tool for the job” was one of his favorites. Nothing put a bee in his bonnet like using the “wrong tool”. He would grimace in mortal agony if you took a pair of pliers to a hex nut. Pa would invariably stop in the middle of a project, climb into our ancient AMC Rebel station wagon and truck on over to Sears to buy the “right tool”. He built up a collection of the “right tools” along the way.
I was talking with one of our portfolio company CEOs the other day about a project we were about to undertake. During the discussion he asked me what I would consider to be the “right tools” for this project. And that, dear friends and colleagues makes software development such an interesting little combination of science and art. There are often lots of “right tools” for a software project. Fans of one particular language or database are bound to howl in anger over this last statement. And yet, it’s true, even if you don’t want it to be true. Sure, there are usually some obvious WRONG tools for a job, but there is often no single “right tool” for the job. PHP is probably a poor choice for writing an operating system. On the flip side, PHP, Perl, Ruby, ASP.Net, Node.js and Java are all credible choices for building a web application.
The CEO oftens faces this development dilemma. Your team wants to build their next module using, let’s say, Ruby on Rails with MongoDB as the database. Is this the right tool for the job? How can you tell if there is no single “right tool”? You can’t know.
In my experience, adding new libraries or 3rd party tools is “easy”. Adding new programming languages is hard. Changing databases is really hard. Changing operating systems is really, REALLY hard. Lots of smart technologists will disagree with those last statements. But here’s the thing. I’m not telling you what I think is risky. I’m telling you what has burned me across dozens of portfolio companies and hundreds of customers over a thirty year career.
As the CEO you don’t want to discourage your team from adding tools to their toolboxes. But in the middle market it is reasonable to stay down the middle of the fairway. Don’t let your technology stack get too old. When your vendor has stopped supporting your language or database or operating system – you’ve waited too long. If your developers are proposing a technology way out front on the Gartner Hype Cycle, then you need to think about putting on the brakes.
Most important of all – you aren’t Facebook or Google or Twitter. In the vast, vast majority of cases you will never need to achieve the same levels of scalability or reliability as these industry behemoths. You don’t need the same tooling these big guys use.
Talk to somebody else that has made the leap you are planning on making. Feel free to pick up the phone and call us – we’re always happy to connect the dots for people.
I’ll leave you with this last little nugget from Pa. I hope it drives you as crazy as it always drove me.
When a task is first begun, never leave it ’til it’s done. Be the labor great or small, do it well or not at all.