In recent time I have got interested in success factors of software libraries, and especially what role developer friendliness plays in that context. But then, what is developer friendliness, actually? What makes a software library devloper friendly?
From my reading and thinking so far, i came to the conclusion that above all three factors are crucial in making a library developer friendly and also driving its adoption:
- API design
- Documentation
- Tool support
To get an introduction to API design, here's some resources:
- Practical API Design by Jaroslav Tulach - the architect behind NetBeans APIs
- Mapping the Space of API Design Decisions by Jeffrey Stylos and Brad Myers
- Effective Java Second Edition by Joshua Bloch - designer of the Java Collections Framework
- How to Design a Good API & Why it Matters talk by Joshua Bloch
Things that complicate the documentation part are that developers read API docs in very different ways (pop-ups in IDEs vs. reading the whole pages), have different backgrounds and experiences, and differ in skill level. You can't always please everyone, but will have to strike a balance somehow.
The API documentation is also valuable when analyzing the API design itself. When a method introduces new concepts that are not already a natural part of the class/interface-level documentation it could be time to look into other design alternatives. The same goes when something is very hard to explain: maybe it would get easier in an other (class/interface) context?
Regarding tool support Tulach comes up with an interesting point of view:
What matters the most is time to market — that is, the ability to get productive with your library as quickly as possible without knowing it. In other words, it needs to be optimized for developer cluelessness as much as possible. This is important. This is what makes an API or a framework attractive. The question is how to do it.
...
From the time-to-market point of view, the most successful API is the one that is covered with good wizards. It doesn’t matter how the API itself looks. ... Now, this is just for getting up to speed. When things get complicated and people need to deal directly with the API, it’s desirable for it to be approachable, easy to use, and compatible. However, this is about cost of ownership, which always takes a back seat to the time-to-market criterion.
It's easy to think that developers will have to learn how to use your library. But probably they rather want to use it right away with as little learning involved as possible!
0 comments:
Post a Comment