The Developer Experience (DX)
Supporting developer inspiration rather than limiting it
A lot goes into planning a products lifestyle, especially if that product is expected to have a significant commercial appeal.
I have to admit that I haven’t researched this topic before committing and writing a substantial portion of this article and to my surprise this topic has popped up all over the Internet. It’s seems like an interesting topic to explore and you can checkout a few of them right here and here. On the other hand, while those articles and search results yield a great deal of input in what goes into developer experience, I’ll try to provide my thoughts on the subject from a bit different angle. Since there seems to be a slight shift happening in the software development world with the focus hopping from a developers workflow to release schedules and needless product complexity, it only seems fitting to explore what aspects go into the topic of this article.
Planned almost a year ago (with the seed being planted God knows when), the idea for this article has only grown in my mind in the past few years in the software development industry and is eager to escape.
At what point did the industry go wrong with this if we can even call it a wrongful direction? Can we go back to improving the development process without compromising the publishers market’s target values and goals? Can the focus shift back to providing developers the necessary tools to make their coding process a bit more enjoyable?
What follows are some of the areas that I think, define a product usage experience in no particular order.
Creating meaningful API’s
The application programming interface (API) is our way to provide a meaningful communication channel between two entities. It defines a common language (contract) that both parties understand. What can clog-up that communication is an abundance of access points that the service entity tries provide with it’s API contract.
The exposing of only the bare minimum functionalities to the target consumer service through it’s API can result in better justification of the existence of the API in the first place. Any API that leaks it’s inner workings through the service or error messages, other than a potential security risk, also lowers the confidence level of the consumer developer in the product as a whole.
Less options lead to more focus and thought of what a complete developer experience should be and finding the right balance of complexity and usefulness with ease of use. If we are afraid that the lack of options in our API’s would sway away any interested consumers in a ever-growing, feature-rich market, we are losing the sight of makes a product good in the first place and that’s the products reliability and usefulness of the solution it tries to provide.
New features tend lead to product fragmentation and the initially set goal for a product slowly disappears and merges into a messy blob of functionality that has lost its rigidness a long time ago. If made to choose between two competing solutions, guess which one would the developers more likely gravitate towards? The one with the leaking, overly-complex and option-saturated API or the one with the bare minimum, tightly- developed and tested one that also gets the job done with much less overhead and lower learning curve?
While the task of implementing new API’s is usually assigned to the first available developer, it should be at least questioned if the new API’s are meaningful and intuitive enough to be simply assigned to anyone. What is intuitive for one person can be detrimental to another. API documentation is usually left to be drafted by more experienced developers and then checked by other ones for any errors or inconsistencies. Overly complex API’s should be avoided when possible and alternative solutions proposed. Never lose track of the developer for whom you are designing the API in the first place.
Peer testing
So you’ve made an interesting and exiting new framework, API, service and are eager to hear what the development community thinks of it. You’ve published your project on various social media posts, developer channels, blog posts, etc. and now you wait for the feedback. The replies start coming in and they are overwhelmingly positive! Praising the new product you’ve published and the problem solution it provides. Congratulations! You made a great first impression with your project, but this should only be the start. Namely, depending on the size and complexity of your project, the developers from the developing community might not had enough time to fully integrate your solution into their projects or test to the extent needed for a fully production-ready solution.
One important thing to note is that, while not to be underestimated, the developer community providing the feedback might be a very small percentage of the end-developers that could end up using your product. The number of initial peer testers depends on various things: the number of existing developers following your work, your previous success in making developer-consumable products, publishing channels, subscribers, groups, and so on. One thing remains the same, not all of the developers that will consume your product will leave a meaningful review or feedback to help you create a more impacting end-developer experience. The vast majority of the developers that use a product simply don’t extend their impressions about it beyond the office-setting, developer small talk. This is a sad state of things in the software development industry.
The most likely scenarios to happen are the ones where developers don’t provide any kind of feedback, they just use a product or they don’t and in the case of new API’s for a large existing framework, they most likely don’t have any options left. They are simply boxed-in by the over-encompassing shadow of the much larger framework, so they have to use the new API’s or risk much time, effort and cost of switching into a completely new framework. When possible, it’s always a good thing to implement some kind of usage metrics to monitor the said activities of the end consumers. Google/Firebase analytics are a good starting point, but implementing a custom solution is also a valid option if the development budget allows for it.
Since we are already here, we can perhaps question who the developers who provide the feedback are. We already mentioned that only a percentage of the target developer community provides any feedback in the first place. Well, who are they? What’s their previous experience? Do they simply follow the latest developer trends or do they give a bit of thought into what products they end up dedicating their time towards to? How much time did they spend using your product? There are developers out there that look forward to frequent changes and see migration guides as something challenging and something to sharpen their skills with. The truth is that not all developers have the time or patience to constantly ‘tinker’ with hard to justify changes. If we constantly look for feedback in the same peer groups, we could possibly risk losing a more objective oversight into our product. An analogy to this could be if we would constantly ask for feedback from our friends and family members about any work we do. You’ll admit that chances are that we’ll receive a biased opinion and the checks end up being picked up by our product.
Testing, testing
The only way we can guarantee that our product works is to have a bunch of test suits to assert our products functionalities against to.
It should be obvious at this point that only stable and well tested solutions are the ones that even stand a chance to make an impact on the market. No matter how good your solution or big the problem is that it tries to solve, if it can’t be reliable or deterministic at the end, it will always be questionable for the users to use it outside an experimental and proof-of-concept environment.
Any front-facing API should be carefully tested with each change to ensure that the existing functionalities don’t suffer from hasty-executed decisions made in conference rooms. Unless that was the intention, in which case alternative approaches should be communicated to the end users as breaking changes. Braking changes should be kept at the bare minimum.
Is your product often used alongside other third party solutions in some sort of a symbiotic way? May it be the OS platform or development IDE? What is commonly omitted when executing testing procedures is the validation that a product works well with some other third party solutions. If your product requires a specific set of third party solutions and system requirements to be able to function in a proper way, make sure to include profile testing for those requirements as well in your development pipeline.
Forced updates
Are frequent and regular release schedules necessary? Sure, if we have meaningful contributions to add. If we constantly think of new ways to improve our product, may it be with features, extensions, fixes or optimizations, we end up keeping ourselves busy. But, why should we be working on an already pretty much complete solution when we could shift our focus onto something else? Not every product needs to grow into a gigantic tentacle monster of endless and hard to maintain features. Some just need to do one thing and do that thing very well. At some point a product’s update release should phase out into simplistic, but regular maintenance cycles diving into more substantial updates when absolutely necessary for the product to remain relevant on a market.
While frequent updates are almost always welcomed and seen as a sign of developer dedication to a product, they can also be seen as a sign of untested, unpolished or even bad software practices, especially in the case of frequent patches. The developers that consume a service will loose confidence in the publisher and look carefully before trying out their other products in the future. This can be very hard on emerging companies and individuals that aim to make a name for themselves in which case every step should be carefully planned and executed.
Doing one thing GREAT
It’s easy to get carried away with creating a feature-rich product to remain relevant in a competitive market, but time and time again it has been shown that at some point the complexity becomes simply too large to be maintained and each new update becomes a pain.
If the entry point into a product is difficult, or worse yet, if the learning curve for it is very steep right at the beginning, we risk losing a lot of potential customers. This if obviously tied to the product domain. Not every domain has an easy first step to jump into. Being the definitive tool in the business can also open a lot of doors, not the same doors as for a feature-rich product, but a few doors nonetheless. So, it’s always good to keep one eye out on that learning curve.
A significant amount of products have outgrown their initial cocoons over their lifecycles into something unrecognizable with barely any traces of the original spark from which everything came to be in the first place. This is by no means a bad thing and it can be almost considered as expected giving a long enough lifespan of the product and possible shifts in industry trends that happened along the way. How many sales pitches for new API’s, frameworks, applications start of with including the keyword lightweight? Lighter than what? The previous industry-leading software tool? Most likely… There has to be a reason why the promise of something being a lightweight version of something else seems so alluring to the consumer market. Most of the consumers are focused on their end-product and finding a fast way to ship that product and the prospect of wrangling of some larger solutions doesn’t seem like a valid enough option. There’s a reason why so many bare-bone text editors keep creeping up on many favorites lists of software tools. The hassle is real and we aim to avoid them as much as possible.
If we take a look at startup companies, we would see that they usually focus on one thing and that their work mostly consists of trying to make that one thing excel until another company buys them out.
The topics mentioned in this article should at no point interfere with business models of others. Carefully crafted project outlines, roadmaps and business models will most of the times be enough for a product to survive and be kept alive long enough to grow its audience.
Good documentation
Most of us have heard the saying that 6 hours of debugging can save us 5 minutes of reading the documentation. Or something similar at least. As developers we often don’t cultivate the habit of reading through a product’s documentation when engaging in the development process other the occasional venture in the setup-and-install entry points of the said documentation. Is there a particular reason why we do that? Perhaps we were trained by less-effective documentation pages over the years, resulting in our loss of confidence in the very same documentation or are we just used to as developers in the early stages in our developer careers to not put as much effort into writing meaningful documentation for our own projects?
Documentation like any written medium, can either provide satisfaction to the reader or not. A good product documentation drives the potential users through it’s contents and exposing all the relevant data and steps to be taken for various scenarios a user could potentially find themselves in when using a product. Clear and to the point without or minimal ambiguity what an action can do is the way to a developers heart. If users start raising issues for the documentation not being expressive enough or entirely missing key and important aspects, it’s a sure-tell sign that the documentation needs to be updated to address those issues. Developers are often used to browse though various discussion boards, issue trackers long before checking out the product documentation as the first go-to destination for any issues. It’s a habit formed only by bad or “dry” documentation experiences beforehand. It’s interesting to note that most of the accepted answers in the said discussion boards are direct quotes and links from the products documentation pages. This only shows that the documentation is either difficult to navigate through or plain laziness of us as developers to query the documentation first before asking other developers for help.
Writing good documentation should be considered an essential part of software development. Usage examples and short, to-the-point descriptions can go a long way in supporting our main product. A lot of heavy lifting in generating meaningful product documentation can be achieved directly from a project’s source code via code commenting. A good example of how intricate and helpful code commenting can be, can be found on the Go programming language commenting resource page.
There are scenarios where we as developers are usually provided with an existing solution by some other entity in our organization and are left to the mercy of the the same entity if they have skimmed thought the solution’s documentation and found it to be of satisfying, developer-friendly experience levels.
If we are given the task of writing the documentation pages, we should also be sure to provide usage examples in our documentation and, most importantly, test those examples to avoid any confusion and problems potential developers might experience when using our product.
We should aim to write our documentation as a sales pitch for our product or service.
Avoiding contradicting yourself
What happens when developers begin with course-correcting their product or solution year after year?
We heard many tremendous announcements of new releases by various product companies, that promised a lot of things, guides, recommendations only for the next years announcements to contradict all of it. So what happened in that one year? Did the industry change? Perhaps or perhaps the lack of research and thought put into a solution proved to be less adequate and the real-world usage data didn’t align with the expected one, requiring new adjustments to be made. We all make mistakes and that is as natural as it gets. Course correction can almost be expected nowadays. Making a habit of those adjustments is what should be avoided. Being careful when making grandiose announcements is strongly advised. There’s only so much that developers and whole companies will commit themselves to when it comes to constant migrations and course corrections, until they start exploring some other, most likely lightweight alternative solution.
1.0, stable, production ready… A year after those claims, significant issues are still present or they’re being updated on a regular and frequent schedule. Those seemed more like alpha versions now, a year later, don’t they? It is important not to mislead developers into thinking they could include a product into production development when the opposite is most likely. Be sure to label your product correctly or as experimental if not covering the very basics of production deployment, stability.
A significant amount of developments are hungry for the next thing and they have the time and money to experiment with it. What si more likely to happen is that long term supported frameworks, libraries and so on are preferred and usually implemented in large scale projects. For greenfield projects, on the other hand, the shiny new thing might be considered.
Making an ecosystem of services
When an individual or corporation provide multiple services and products, an idea is formed for creating a whole ecosystem for those services. What would be considered as a service ecosystem?
A service ecosystem is a system consisting of at least two sub-services that are “aware” of each other. That awareness comes from the notion that they share common gateway elements that allow them to communicate with each other in some capacity whether that being a common API, design system or some other communication protocol. Do you have a whole existing set of services and products already made? Why not make them communicate in the same language. Teach developers what to expect from your product. A go-to example would be the Apple ecosystem.
What an ecosystem of services provides is a way for the consumers to utilize a sandbox of multiple services that allow them to execute any task without the need to include a new third-party solution at any stage of a tasks execution. What can be potentially considered a downside is that the sandbox paradigm leads to problematic inclusion of other external services when the ecosystem is incomplete or plainly missing a crucial part for a complete workflow and the potential difficulty of exiting that same ecosystem if it proves to be too enclosed.
The exiting from an ecosystem is a two-edged sword. One would ask, as service provides, why would we ever want any customer to ever leave our ecosystem? Too much of a good thing can be hurtful. If the ecosystem is not sustainable in the long-run, any “waves” that manifest as updates and changes to the previous, well-established properties of the said ecosystem can lead to some unforeseen issues with the consumers. If those waves are big enough, the service providers risk alienating any loyal users and drive them towards a competing service or worst yet, a competing ecosystem. Maintaining the fragile balance between maintaining existing values and introducing new ones is an art form in itself. Considering evolution rather than revolution when introducing changes to the ecosystem has proven successful for many large service providers over the years.
Clear vision
At the end, nothing matters more than having a clear vision what a product is, where its extended goals(development roadmap) are and where it fits in a very competitive market. Microcorrectins can go only so far, the long vision is what sets the foundations for something more lasting.
If you don’t have clear vision for your product, don’t expect the developers to have it instead. Don’t let developers drive your product with unnecessary demands that directly interfere with your vision. Acknowledge them and put those ideas on the backstack or into a complete new product if the ideas are too far of your intentional plans/visions. It is what it is. They can end up using it or not. You’ve already provided them the developer experience they were looking for.
We reached a point where we can finally say why DX is as important as, say UX is. DX drives the developers and in general makes their jobs a bit more easier and by extension they will be much happier and willing to use and even promote our product to other developers.
