Top 3 reasons for a bad developer experience
If you are not a software developer then the best analogy for a bad developer experience would be the feelings of frustration you get when you are stuck in traffic because of roadwork. In your mind, you question the planning authorities thought process. They close a lane during peak hours and cause inexplicable congestion, impacting the lives of commuters that have work to do. Instead of working at night and finishing before the morning.
This analogy is amazing because;
You are impacted by authority and have no voice in the decision-making.
Doing the roadwork at night seems to be a better solution from your perspective.
The roadwork has very real consequences for you and other drivers. Believe it or not, there are millions of software developers that work daily in an environment where they are inconvenienced like this. The developer experience (devex) is a concept that tries to manage and measure the ease with which it takes to create software within an organisation. I want to write about the top causes of a bad developer experience. Ready, set, go... With my analogy complete, I'm sure you have some empathy for your software development colleagues. It is so hard to do great work when it takes an extra thirty minutes to just get to work nevermind this process feels like groundhog day because unlike you who commute twice a day the software developer commits frequently during the day so this analogy scales linearly. The most common causes of bottlenecks range from sub-optimal tools, complex workflows and overused resources.
Suboptimal Tools
CICD with no Concurrency
Software development tooling can be quite pricey when you factor in aspects like concurrency and build speed. As a result, you decide to use a free or entry-level plan that intentionally prevents concurrency. In SaaS products, concurrency is a premium feature because it is valuable to organisations like yours. The worst case is when you have two SaaS tools that lack concurrency because, in cases like this, your CICD will be out of action while they handle workloads.
When we set up the managed Jenkins service, we wanted all our plans to have enough concurrency to allow you to create optimal developer experiences. The small Jenkins controller is capable of up to 8X concurrency. Even the nano Jenkins controller has concurrency capabilities.
Slow Builds
Building software requires an optimum amount of computing resources to enable you to complete the workload efficiently. Finding the optimal point is quite a challenge and requires some experimentation; however, it can save you on your build costs and reduce the time your developers spend waiting for builds to complete.
As part of our Jenkins Build Service support we help our customers optimise the build workloads at no cost by looking at how long the builds take and selecting the right compute resources to handle the workloads.
Unmaintained Tools
Never underestimate how quickly something that has not been maintained can begin to slow down. Any CI Server has complex dependencies that can unintentionally slow down when the underlying platform is not maintained. One of the major tests for us is how snappy the load time is for the CI server. If it takes time to load your build jobs, then it will also cost time for the developers when they need to dig into build logs to do some triage.
No feedback
How does the developer know if there was a failed test or build? Giving feedback should be automated into your workflows so that if there is a failure, the developer gets notified by Slack, Teams or Mattermost immediately. Adding links to the build to the notification can help them get into the CI Server faster and begin triaging the reasons. Suboptimal tooling can impact the developer experience in so many ways we recommend creating open channels for communication around tooling. If maintenance is an issue look for a provider that is a specialist in software development tools and understands the importance of the developer experience.
Complex Workflows
Workflows are responsible for automating the development process. They instruct the CI Server on how to build the software and integrate static analysis tools, testing services and deployment for non-production and production deployments, amongst many other responsibilities. Understandably, workflows can slow down the developer experience. In our experience serving hundreds of customers over the past few years, we have to constantly manage how long workflows take to complete and if there is a trend towards longer workflows, we look at ways to optimise them.
Complex workflows are challenging to work with and even harder to optimise because, in many cases, the optimisation process needs to happen in a few areas for the whole workflow to be viable. The complexity increases when you add a tool that is not necessarily optimised for inclusion into a workflow. We recommend considering the value the tools provide to developers when included in a workflow. If a tool offers no value to the developer and is purely there for other purposes, then it should be added to workflows that do not impact the developer experience. Consider this a mirror of the roadwork analogy.
Complicated Bureaucracy
Organisations can easily burden their people with bureaucracy. However, it comes with hidden costs that can hinder progress and generate frustration. The issue with bureaucracy is it is the most inconvenient way to improve anything; however, in many cases, it is touted as part of your continuous improvement process. I'm sure that is also what the authorities think when they keep one lane open. We've done a few projects with organisations with demanding bureaucratic requirements, and our approach is to integrate the discovery phases into workflows that do not impact the developer experience. Any developer will agree to extract value from the workflow in this way. As a result, when it comes to releases, your organisation will have details of all the non-functional requirements in a change request somewhere, all generated by the workflow while it worked on building and testing software. To avoid impacting the developer experience in workflows, we recommend;
In feature branches run any tests that improves the developer experience. This includes static analysis, unit tests, functional tests and linting.
Integrate feedback on successful stage completion as necessary to improve the developer experience.
In main branches run end to end tests, avoid rebuilding and once tests pass progress to the next stage.
Integrate the outcomes of all tests into the generation of release notes and change requests as per your organisations requirements.
In conclusion, the main workflows that impact the developer experience are the development environment and feature branch workflows as they are the most commonly used when working day-to-day. Keep these lean and with essential processes that boost the developer experience.
If you need assistance with your software development tooling and the developer experience our DevOps-As-A-Service can help improve the developer experience.
Happy Developing!
Our customers highly rate us.
