Good Technology

From APIDesign

What makes a Technology good? What made some people to select one technology over another? What a designer needs to concentrated on when creating a library or framework to make it good, successful, widely accepted? This page highlights the common principles that make things work.

Time To Market

Evaluation of any software technology starts with downloading, installing and trying to create simple hello world application. The faster one can do this, the less obstacles are found in a way, the better perception such technology gets. Of course, there is a long way from a hello world demo, to the final release, yet the first perception counts.

Just download Ruby on Rails and create your website. The only thing that you need to do is to execute a command in a shell and you have a running application. The application does not do much, but it took just seconds to create it. How can such technology be bad!?

An important aspect that helps the Time To Market perception is Cluelessness. If the library or framework can be used immediately, without reading bunch of materials. If one can write code without studying the whole API. If the code can execute and do something meaningful, as soon as it is compiled, then the entry barrier is lowered, and the Time To Market made smaller.

What implication does this have with respect to APIs of our libraries? They need to be easy to use, navigate, they need to be self documenting. On the other hand, one can substitute much of this functionality with the Ruby on Rails trick: having templates, tutorials, premade samples, that can just be taken and used instantly serves this purpose well too. Good tools can make every API simple to start with...

Total Cost of Ownership

However life cycle of a software product is not over after releasing first version. Especially in case of successful products, there will be many subsequent revisions. Creation of these new versions puts fundamentally different requirements on the underlying technology - it is no longer important how fast it is to write new code. It is more important whether the existing code can be read, debugged and modified without introducing major regressions. It is important whether one can safely upgrade to newer version of underlying framework or technology without being afraid of BackwardCompatibility problems.

The implications of this life cycle phase on the shape of APIs of our libraries is quite different to the initial to market phase. The code created using such API needs to be readable, preferably by other person than just the author of the code. And especially, APIs for a Good Technology shall not stimulate Fear of Upgrades syndrome.

Coolness

It definitely helps if a technology can be seen as being cool. People like to talk about cool things, like to show to others that they follow the trends and as such technology that is cool, is easier to market and to spread.

Being cool can be achieved in many forms. One can follow the cool trends, talk about such technology using buzzwords or even give the technology Good Name.

On the other hand, if there is technology that is just cool, and it does not help at all with Time To Market or its Cost of Ownership is known to be too high, then no amount of coolness can compensate that and in long term the technology is destined to be seen as poor, and not as good.

<comments/>