Success MatrixWed, 29th Sep '10, 6:30 pm::
I spent a considerable time this past month learning new systems, platforms, and tools to improve my skills in programming. Choosing what to learn is often quite a difficult task of its own because you never know how the 200 hours you spent learning a new technology will impact your skills, creativity, and the very way you think. One important thing I learnt while learning to learn is how to distinguish between tools and raw materials, and more importantly, why.
Tools are what you build the product with. Raw materials are what the product is built of. The fable of The Chicken and the Pig would be quiet appropriate here: No matter what you build, tools are involved but raw materials are committed. I used to spend a lot of time picking the right tools for the right job because that's what you're supposed to do. Yet I saw lots of examples of really crappy tools being used improperly in very successful products. On the other hand, I also saw very good tools being used properly in products that failed miserably. How could there be no correlation between the input and output? Turns out I was only looking at part of the input. What I should have been concentrating on, was the combination of the raw materials and tools:
Success Matrix | Strong Materials | Poor Materials |
---|---|---|
Strong Tools | Designed to succeed | Awaiting disaster |
Poor Tools | Awaiting sweat & blood | Designed to fail |
Having a successful product certainly requires a lot more than strong raw materials and tools but having those two right gives you a strong foundation. That buildings and bridges built with poor materials fall is no shocker. What does surprise people every now and then is seeing something built with poor tools succeed. These products require a lot more sweat and blood to succeed but they can succeed indeed. I don't have first-hand knowledge working with the following tech sites but based on the information I've gathered from articles, interviews, and online postings, I would classify them in the success matrix as:
Success Matrix | Strong Materials | Poor Materials |
---|---|---|
Strong Tools | DropBox | Xmarks |
Poor Tools | Orkut | Cuil |
The problem with technology (and the primary reason I decided to write this post) is that it is difficult to decide what is a tool and what is a raw material when in the end, it's just a bunch of 1s and 0s. If you're building a shed, wood and nails are raw material, axe and hammer are tools - no ambiguity at all. But for a web project, is the back-end database a tool or a raw material? What about the platform, the programming language, the framework, the client-end scripting library, the graphics engine, or the server host?
Since the difference is hard to spot, the question is if it even matters or not. I'd say it does, for one simple reason - raw materials cannot be changed after you've started building the product whereas tools can be, albeit at a minor cost. You can't switch from wood to cement half-way through a building project but you can certainly upgrade to a nail-gun from a hammer when your arms get tired. Using the ability-to-be-swapped as the primary condition, it can be easy to decide if something is a raw material or a tool in a tech project. Hosting? Usually a tool, unless you build your project solely for AWS. Programming language and framework? Usually a raw material unless the back-end is what's doing the bulk of the hard work and the front-end is simply a pretty proxy. Database engine? Could be a swappable tool if you abstract away all database-specific calls from your code.
Programmers often get into long arguments about which technology is right for the job and why you should use X and never use Y. Fact of the matter is, if something is a raw material for your product, take the time and do the research to make an educated guess. It will always be a guess because you never know what will happen in the future. If something is a tool, just pick something that gets you going quickly because if it doesn't work, you can always switch to something else later.