Good Technology
From APIDesign
| Line 6: | Line 6: | ||
Just download [[wikipedia::Ruby on Rails|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 too just seconds to create it. How can such technology be bad!? | Just download [[wikipedia::Ruby on Rails|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 too 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 [[API]]s 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 [[wikipedia::Ruby on Rails|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]] == | == 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 [[API]]s 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, [[API]]s for a [[Good Technology]] shall not stimulate [[Fear of Upgrades]] syndrome. | ||
== Coolness == | == Coolness == | ||
Revision as of 18:08, 3 November 2008
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 too 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 spread.
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, not good.
Follow
