Again, this famous 'X', as in UX. It's all about experience. The good experience is the key that makes a product valuable. We are always talking about user experience, but here in this post, I am going to talk about developer experience. As a developer, you may use lots of libraries and frameworks. But, what makes you to feel better about some of them? It is developer experience or DX for short.
Developer Experience (DX): The experience of a developer while working with a specific library, framework or platform.
For end users, GUI (Graphical User Interface) affects their experience. For developers, API (Application Programming Interface) is the key. Developers (as end users of platform) work with API which makes their experience. In the article "Effective Developer Experience (DX)", Jeremiah Lee Cohick says:
The usability of an API can be determined by how easily a developer achieve a goal on behalf of an end user. Developers should be able to intuit the correct manner by which to interact with the platform. Best practices for code organization, design patterns, and naming conventions should be consistent and communicated. Usability also extends to error and status messages. When errors do occur, developers need to be able to easily identify where the problem occurred and what specifically was unexpected.
Dotability: A Metric for DX
How can you measure DX of a library, framework or a platform? Dotability is a metric I've invented for myself to create better platforms.
A platform consists of classes, methods, properties and .... From now, I call them platform artifacts.
Platform Artifacts: classes, methods, properties, interfaces, ...
What happens if you put a dot on a platform artifact?
What list will Intellisense show to the developer?
- How readable is this list?
- How intuitive is this list?
Consider some DataTime class with this methods:
DaysAdd(int value) DaysSubtract(int value) MinutesAdd(int value) MinutesSubtract(int value) HoursAdd(int value) HoursSubtract(int value) SecondsAdd(int value) SecondsSubtract(int value)
Using this naming, if developer writes myDay.Days, IntelliSense shows DaysAdd and DaysSubtract methods in a menu.
Days -> (put dot) -> (IntelliSense menu):
- DaysAdd
- DaysSubtract
But if she writes myDate.Add it shows nothing, as no method name starts with Add.
As it is more often happening for developers to type Add in comparison to type Days, it is more convenient to use this naming for methods:
AddDays(int value) AddHours(int value) AddMinutes(int value) AddSeconds(int value) SubtractDays(int value) SubtractHours(int value) SubtractMinutes(int value) SubtractSeconds(int value)
So I she writes Add, this list appears:
- AddDays
- AddHours
- AddMinutes
- AddSeconds
This is what I call: "A more Dotable API", as you can see. The API should be designed in a way that every developer enjoy exploring your framework by putting dots.
Learning frameworks via exploration by putting dots is very popular among developers.
So, this an important factor for a library or framework to get popular.
The more your framework is Dotable, with a higher chance it is a popular framework.
