The term User Experience is well-known to all of us. It’s deeply integrated in the Agile methodology, forcing us to write User Stories, to perform User Testing, and to keep the user central in every little decision we make throughout the day, whether we are a business analyst, a developer or any of the other roles required to deliver a product.
The term Developer Experience is not that common. It was coined about four years ago in regards to API usability. The gist is that using a third-party API should be simple, intuitive and fun, in the same way a User Interface should be to a user.
It has been a quality that many, if not all, successful tech products have focussed on from day one. It’s one of the reasons Facebook won the battle against MySpace, and one of the reasons that the first release of iOS, while quite low on features, found so much adoption.
But I feel the term can be applied in a broader sense. It applies to a developer’s hardware, software tools and internet connection. It applies to the feasibility of deadlines, but most of all, it applies to listening to your developers. Every developer wants to deliver quality. Give them the chance and they will start applying unit testing, code reviews, continuous integration; all tools that will have a direct positive impact on the quality of the product.
Corporate development environments
For the last 18 months, I’ve been involved in a multi-million Euro project at, and managed by, one of our bigger clients. The client is working on integrating Agile SCRUM into their entire workflow. The scrum teams work with a sprint planning, daily stand-up, retrospectives; all by the book.
But the output of the teams has been different than what I’m used to at MOBGEN. It took over 12 months to have a first releasable product out to the first users. So what is going wrong?
The developer experience is subpar. A few examples:
- As the use of Bitbucket and Github is forbidden by the company policies, we ended up creating a Git repository on a USB stick and passing that around until the policy was finally changed.
- Missing documentation or outside assistance for the projects closed-source software
- Outdated versions of tools and frameworks.
- No continuous integration set-up.
- No support for GIT, forcing complex branching workflows in Subversion
There is a constant focus on delivering story points and making deadlines, but there is not enough focus on improving the actual output of the development team, or on spending time on getting rid of the technical debt.
None of these things are surprising in a corporate environment. There is an understandable need for (security) policies, which makes these kinds of challenges extremely difficult to overcome.
My time there has been a huge learning experience. I learned how to work inside a big corporate project, and I learned the challenges that come along with it. I’ve seen the correlation between developer experience and the throughput and quality of the product.
Most of all, I’ve learned how privileged I am that at MOBGEN we’ve succeeded in keeping a startup like environment, where we hold the developer experience in high regard.