Editor’s Note: Celestine Ezeokoye co-founded and currently runs Tiketmobile, an application looking to disrupt transportation in Africa, allowing travellers easily find, compare prices and buy bus tickets, a first of many tech companies he’s looking to build across Africa. He studied Computer Science at the University of Lagos, and represented Nigeria twice at the Microsoft Imagine Cup. He has decided to share his experience with other (aspiring) founders in the ‘Start-ups On’ series. You can read his post – Start-ups on Decision and Market, and follow him on twitter or his blog.
Many times there are usually arguments about which technology is best to build a product. These arguments usually start when a new start-up want to start building and the outcome may kill or accelerate the drive to build. The founders may end-up picking-up a “cool-kid” tool as their choice and end-up spending otherwise development time learning. Or they might pick an inappropriate technology and spend most time trying to find workarounds.
Been there, done that, got the T-shirt! So I’ll let you know how I deal with it.
The best way to look at these things is to see them as tools. When a plumber wants to fix a leaking pipe, he goes to the work location with a toolbox. From there, he decides which tool is best for the task at hand. If he needs a set of pliers, he would tell from observing the job. If it’s plunger he needs, he would also decide from observation. He doesn’t say ahead of time, “I’ll just go there with my plunger and whatever happens, the plunger would fix it. After all, it fixed the last fault I was consulted for.” This is the way of the tools man: use the tool that is best suited for the job at hand. Developers are tools men and these should be our way.
A personal ordeal
I first learnt this in 2007 when I had to learn .NET to enter for The Imagine Cup. Prior to that, I was a Java guy, simple! I had coded for 2 years and was in my first year in the university when Microsoft came around to introduce the Imagine Cup to students. Then, I coded in Java – hard-core – but I wanted to take part so I had to learn .NET.
The point was cemented two years later, when I was in my third year. I had subscribed for Oracle Magazine a few months back and they had this issue about programming technologies being tools for solving problems. Stressing the points that the more tools you had at your disposal, the better decisions you can take. I read and absorbed the points. Also, following tech-engineering blogs like Facebook Engineering Notes also helped to drive home the points. From then I picked-up any Language I had a chance to learn – Scala, Erlang, Clojure, etc and I was open to more.
Going about acquiring and using these tools
For those who only develop on one platform these may be strange points, because all they can use is that platform. However, for the others who have picked-up a good number of tools, they would find them handy in different circumstances, at different times. As a developer, learn as many languages/technologies as you have an opportunity to learn. You could be biased towards one (I still am towards Java), but it shouldn’t stop you from using the one that’s best suited for the task at hand, at any particular time.
Decisions as to which tools to use should be taken with a lot of things in mind. These include cost of hosting, availability of skilled personnel, support, etc.
Don’t be a man whose only tool is a hammer; hence everything should be a nail. In the end, your users do not care about what you used during development; they just want your product to work.
[image via Flickr/ mikefisher821]
