CWDN series: Developer eXperience - Introduction & brief

Building cross-functionality

Why would we care about DX in the first place then? Because when CIOs and project managers create positive working environments with the right software tools, the right constructs and methodologies, the right people management approach and the right amount of cola in the soda machine… then (and only then) can they start to build out cross-functional teams that can work effectively across organisational and geographic boundaries, using their preferred tooling.

Questions arise here immediately. If we are suggesting that good DX breeds good applications, then by what measure do we quantify and qualify the ‘good’ factor in the first place – and how much better than ‘just good enough’ is really good anyway?

Is good DX a more developer-driven individualistic approach, or is it always essentially a mandate that management needs to fulfil upon? We can reasonably assume that all good DX occurs in coding teams that recognise meritocracy over and above any form of hierarchy, so how does management juggle that fine balance and still play a useful role in team guidance and direction?

Full-stack DX

As we consider the elements in positive DX environments, how much of a full-stack experience are we talking about here? Should we focus primarily on software application development tools – or should we absolutely equally also examine which APIs, SDKs, libraries and dependencies are at play – the question is, just how granular do we need to go with our DX measure?

Users matter too of course. So should good DX always result in happy users or not? As we know, it is possible to finalise requirements gathering, work through User Acceptance Testing (UAT) and even extend into application augmentation, custom tuning and realignment and still get unhappy users – does a good DX with poor user feedback still count as good DX?

We also need to equate DX with user productivity, are the two inextricably linked, are they uncommon bedfellows that sometimes come together when the stars are aligned, or indeed are they ever mutually exclusive? If a software project is running along smoothly, but could do better, are the introduction or new tools and technologies always a positive boost for DX – or, conversely, does the learning curve and extra burden that naturally results here actually offset the DX boost that was intended in the first place.

Automation situation

With so many automation accelerators now being brought to bear, should we be looking to exert the benefits of self-service and no-code software functionality as a prime enabler for better DX? On paper, it feels like we should, but any quick fixes at this level are unlikely to be plug-and-play simple – even if they are plug-and-play drag-and-drop in terms of the way they are used.

Developers aren’t always the most social creatures, but the question of collaboration is surely key to analysing DX. With code constructs that may feature merges, commits and interconnects of various forms all being engineered at any one time, how much does team-joined-up-ness matter within departments – and of course across those cross-functional teams that we mentioned right at the start?

Although collaboration is important, does too much collaboration start to become counter-intuitive? Should good DX be able to measure ‘white noise’ and start to flag up issues when not enough developer development time is being used as actual hard-core (or low-code) development time?

According to Microsoft, “Developer experience refers to how easy or difficult it is for a developer to perform essential tasks needed to implement a change. A positive developer experience would mean these tasks are relatively easy for the team (see measures below).”

• Build – Verify that changes are free of syntax error and compile.
  
• Test – Verify that all automated tests pass.
  
• Start – Launch end-to-end to simulate execution in a deployed environment.
  
• Debug – Attach debugger to started solution, set breakpoints, step through code and inspect variables.
  

If this sounds a little clinical, it need not, this is binary yes or no stuff and it should appeal to software engineers from a base level. Microsoft likes to talk about the increased velocity & quality that comes from good DX – it’s all about giving developers the opportunity to spend less time on non-value-add activities such as dev/local environment setup, waiting on remote environments to test and rework to fix defects.

Behold, the DX champion!

Sometimes known as the DX Lead, sometimes known as the DevEx Champion or DX Advocate/Evangelist, this whole effort may be one person taking the lead and promote developer goodness and wellness throughout. But this is technology democratisation, so don’t be surprised to find that that position is ‘rotating’ to enable others to lead the vanguard. Further here, how should we work to establish Developer Experience Owners (DXOs) i.e. individually aligned championed that have segmented responsibilities for elements of DX and specific tools.

How about onboarding guides? At what level should this be a core part of DX planning? How crucial is standardisation in DX i.e. how important is it for each application component to be instantiated, checked and stopped in a simplified manner in order for newcomers to get with the program programme quickly and for old timers to know it just works?

Krzysztof Wróbel, director of engineering at Codilime, proposes three pillars of developer experience: usability, findability and credibility – so how true is this proposition and does s every good DX have a solid workflow system?

Technically speaking, does a smaller number of code repositories mean better DX? Think about the impact that has on change requests… we can go deep below the command line here and upwards in the touchy-feely aspects developer experiences all the way up to fist bumps, high-fives and back rubs if needed.

Let’s embark on the DX express and try to map out this new and emerging route to happiness and better applications.

Only one question remains, do we say Developer eXperience, Dev-eX, DevEX or plain old developer experience and DX?

Free image source (above & below): Wikimedia Commons