Every day writing code we make many design decisions about naming and encapsulation of functionality. Our primary concern is to express our code in a way that can easily be understood at a later date so changes can be made cleanly. To this end, we've learned to organise our code into smaller elements that can be composed neatly to support system behaviours, as where code gets complicated misunderstandings can happen.
When trying to figure out code quality, developers normally lean on software to analyse code complexity and test coverage. Perhaps we might learn more about how good our design is by starting to apply techniques from UX to measure DX (Developer eXperience)?
Developers are primary users of our software design, often working across a vast and complex codebase that's difficult to navigate around. Sometimes our code terrain is too crowded with repurposed junk and other times it's hard to see the wood for the trees with no easy landmarks to navigate by. We could start to measure how easy the code is for developers to navigate. How long does it take a developer to pinpoint the location of code to change? How many places do they look before finding the relevant areas to change? etc.
My interest in DX was rekindled by a recent discussion at SoCraTes on “What is good software design?”. I sighed inwardly when the topic was chosen by the crowd and if I hadn't been on facilitator duty, I'd probably have skipped the discussion entirely. How wrong I was! I’ll try to sum up the highlights and link to some earlier thoughts I had on topic of DX following a talk at London's Design Museum on the usability of Underground maps.
We ran this evening discussion as a Fish Bowl — you can only comment on the discussion topic, if you are in the 'bowl' — 4 chairs at the front. One chair is always kept empty, to allow anyone in the room to jump in with a question or share some relevant information. The "fish" in this photo are: Chris Jeffery, Mashooq Badar, Steve Hayes but many people jumped in and out of our conversation. Here are some of the points that I found most interesting:
Design is how we layout the code to make it easy to maintain. It may appear that there’s no external impact of software design and it's pretty intangibe how we evaluate one design over another. However, there are measurable external affects on staff retention, ease of change and developer mood. Corey Haines has been working on Mercury App, a tool which can be used by a developer to track their mood over time.
Steve Tooke mentioned Sandi Metz's TRUE criteria for design judgement
- Transparent
- Reasonable
- Usable
- Exemplary
We talked about designing for use and as developers are primary users of our code perhaps we should think more about the developers who come after us. Brian Marick has summarised good code as that which brings joy to those who come after (users and programmers). Maybe we can aspire to bring joy to developers who read our code months or years after we write it! We could apply techniques from UX practitioners to start measuring accessibility and navigability of our codebases. We could use our findings to identify worst pain points, bringing focus to our cleanup attempts and measure whether working conditions have improved through user testing. Dmitry urged us to "Track everything that developers do!"
And Anna Jayne added via #SoCraTesUK twitter stream that we already sort of do in WTFs per min!
All this reminded me that I had some similar thoughts about measuring DX last year. My fascination for maps took me to London’s Design Museum to hear a talk by cognitive psychologist, Maxwell Roberts, who has been measuring the effectiveness of different layouts of underground maps. I thought the same approach might be used to assess the accessibility of different software designs/architectures, sort of UX from a programmer perspective.
I also heard at SoCraTes that DX of API’s is already being tested see this post from Pamela Fox and Jeremiah Lee has also run some workshops on DX at SXSW and Fluent conf
At the Design Museum, Maxwell talked about "information pollution" and how we want to reduce cognitive load for users in processing what they see in front of them. It also helps if a map doesn't significantly conflict with their mental model of the actual topography of the city. Clearly cognitive load must be a big factor in understanding the software design, as we try to figure out where to insert behaviours into a software system. Although we try to use meaningful names to help make code self-explanatory perhaps when a developer is confronted train wreck of long names in a literal programming style iit actually makes it harder to see the structure than using shorter names. We could test this kind of thing using DX.
Also the comparison of a underground map and city topography (people find London underground map easier when the Thames river is shown) might be similar to the software architecture/metaphor matching to real-world domain.
Maxwell's point was that people often use same design rules without thinking about whether they are the best possible for the problem. He's a proponent of a UX technique - Evidence Based Information Design and has been doing testing of different underground map designs for the same city (octolinear/hexalinear vs curves, etc). He takes objective measures: how long does it take a user to do X? Where X might be station finding or journey planning. He also takes subjective measures: how to users rate the map? which map would they choose?
His findings are interesting. Subjective measures on aesthetics don't correlate with which map is quicker to use. People like designs which seem familiar even though tests show that other designs are quicker to navigate. I thought of how conventional/familiar coding styles put developers at ease even though actual design may be a bad fit for a problem.
His design principles for maps were:
- Simplicity
- Coherence (shape/structure)
- Balance
- Harmony
- Topography alignment
- Reduce supplementaty info
When we create maps we want to map topography and reveal structure but we may need to discard current conventions to do so. We should beware following tradition without theory about why it's being applied to this particular problem. For underground maps, people are too hooked on octolinear style (following early success of London underground map in 1930's) but other styles are better for different city geographies. Perhaps in software development we are too used to OOD conventions to see that this can obscure design.
One of the last points made in our discussion at SoCraTes is one from Christopher Alexander, whose work on architectural patterns inspired many software developers to mine design patterns for software. Apparently Alexander’s advice to the software community at an OOPSLA conference was “Don’t extract the humanity” and perhaps by starting to test DX this could be a start of putting developers to the forefront of evaluating good design practice. Let’s try to write better code for the developer who comes after us by testing developer reactions now.
Recent Comments