Blank slate

I’m a fan of the original Sherlock Holmes books, and there are a few things in them that talk about an enlightenment way of thinking that’s useful for a developer when gathering requirements (whether tomes, user stories, backlog ideas,etc), writing code or approaching debugging.

Today I want to talk a bit about A Study in Scarlet, and the early conversations between Holmes and Watson before their first case together, because they capture the essence of his enlightenment thinking very well.

Ignore Irrelevant detail

Watson tells Holmes that the sun rotates around the earth, as he is surprised that an educated man does not know this. In reply, Holmes says,
“That’s very interesting, I will now do my best to forget it”

It’s not an important factor in any of his cases, it doesn’t affect his work, so it’s not a fact he needs to record. He accepts it but has no way to act on that information, so he dismisses it.

It’s something that is often hard to do in requirements gathering and may need to be done retrospectively after you find out whether Andy from finance’s love for Richard Branson is just infatuation, or it means that every call to action across your site will need to be red.

It’s also something to apply more generally, choose what to ignore, don’t learn every new JS framework. Don’t expect to be an expert in everything. Be content with being T-shaped, and become an expert in solving problems and focusing on the right details.

The Book of Life

” it attempted to show how much an observant man might learn by an accurate and systematic examination of all that came in his way.”

The truth is never simple. Whatever you build will be part of an ecosystem comprised of other software, of manual processes, of fallible humans, and the winds of fate.

Gather whatever information you can, in whatever detail you can. Organise it and understand the bigger context.

The Phoenix Project has a great understanding of this in the discussion of the SOX-404 audit, where the IT department are busy worrying about controls on software without understanding the manual processes surrounding the software and how that fits into the compliance picture.


On their journey to their first case together, Watson is keen to speculate about the motives and means that led to the crime, extrapolating from what little information they got from the initial introduction.

Holmes quickly and sternly cut Watson off from that line of thinking. He was clear that he would also base hypotheses on the causes and consequences once he had evidence before him to narrow down the possibilities, removing the impossible.

Speculate make hypotheses on why the system failed, on what will improve sales, on what the performance bottleneck is really going to be. Without data or a way to test them, they are useless for reaching understanding. Sometimes the beauty of a forest can only be appreciated by the birds.

Remove your preconceptions and bias from judgement by understanding what they are. Follow the data instead of your gut.

development ux

Work hard to make things simple

Bowling Alley

“Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction.” ERNST F. SCHUMACHER

It’s easy to write software. Ask users what they want (or even better, observe them and discover their problems), find a clean, user-friendly solution, build it and deliver it, for free, with no ads.

And you make a success of it, so you add more features to see off the competition, or to disrupt a new market. Google built Gmail, then added automatic categories, and Smart Replies to make it easier to process your messages. And they also added Wave, Buzz, Google+, Talk and others, to demonstrate other ways to connect and communicate, for places where email doesn’t work so well. So many new features, new things to learn, spinning out from that new core.

And yet Gmail remains popular, the rest, not so much.

It’s easy to add features. With a bit of work, you can even add them seamlessly without adding another menu option that your users will never see.

But what’s your plan to remove options, to streamline your code? How do add a new feature that’s easily discoverable and useful? How can you be smart and subtle?

What is your simplification strategy?


The frustration of confounding expectations

Icons on the microwave : heat water with a spoon in it. There is a glass of water without a spoon with a cross through it.
Spoons in the microwave

After years of being told no metal in microwave, it still feels too weird to follow the instructions on my new microwave to use a spoon when boiling water. There’s a sticker telling me I have to add a spoon when microwaving water but I don’t see myself ever doing that because the “no metal” is so ingrained, and I’ve seen plenty of lightning videos from people who have done it.

A lift control panel with a numeric keypad and the letter C in the display
Abstraction in lift design

This picture is from the lifts at the local hospital. You press a floor number (rather than up/down) and the display responds with a letter telling you which lift to catch. This additional abstraction confuses many users, as I discovered helping people use them as I was taking a coffee break.

I see the same thing on a lot of websites. Those “cool” websites that break scrolling by moving things sideways or zoom in as I scroll down. SPA sites that break the back button. Using outlook web access on a mobile browser is painful. I keep getting the “Are you sure you want to resend?” or the login prompt when I try to go back to my message list from an email.

I’ve never been a great visual web designer, I’m definitely a function-over-form type, but I’ve always started with the principles that came to be known as progressive enhancement. Make it work in the simplest way, and add the bells and whistles on top of a strong, accessible foundation. That foundation has shifted from HTML, to HTML+CSS+JS, to TSX in my latest projects, and from desktop to mobile throughout, but it is always based on the basic principles of text and forms : easy to read, easy to follow, and works the way you expect it to.

If you’re trying hard to stand out by breaking expectations, what are you trying to hide?

development leadership quickfix ux wtf

De-pluralisation: strategic blinkers

The process of de-pluralisation takes all your existing problems and combines them into one simple manageable problem: “it’s JavaScript”, “it’s Windows”, “it’s the CDO” with a simple manageable solution “kill it”. Like all simple solutions it’s almost always wrong.

“People aren’t complying with our data quality. Users keep putting in wrong email addresses.”

“The new computer system will fix that”

“Users complain that there’s too many steps to sign off expenses”

“Each step will be faster in the new computer system”

“Staff have low job satisfaction”

“New computer system!”

“Our users aren’t interested in that new feature”

“New computer system!”

“We’ve been hacked with a social engineering attack”


Changing one thing is rarely the answer. There are many pain points and problems we all face day to day. It’s tempting to try and fix them all together, but unless you understand why the problem exists and what the parameters are to fix that problem, you can’t fix it.

Sometimes New Computer System (TM) will fix multiple problems, if they’ve been defined and the system has been designed to do so. But don’t expect it to fix everything because it’s new. That’s how to make people disenchanted.

If you think one system will rule them all, you may as well throw your team in the fire now before you waste time and money on a misguided transformation.

development programming

Working exactly to spec

Is there a problem?

  • The work was completed to spec.
  • Any additional work was likely to break the time and cost estimates.
  • The work meets the current standards. To bring the remaining paintwork up to standard would require removing and re-implementing the solution, further risking budgets and blocking higher priority work.
  • The only available colours do not provide the legacy appearance required to match the existing lines.
  • The blue lines were not part of the original specification and therefore no knowledge is available on their purpose and whether they should be extended or removed.
  • The disjointed yellow line on the right-hand side would require straightening, which would cause confusion to existing users. There are multiple consistent configurations and the workers have no means to evaluate which of these minimises confusion.
  • The user who raised the bug report is unaware of the timetable detailing the repainting plan and the agreed extent of the lines.
  • The user who raised the bug report is unaware of future proposed fixes that will require additional upheaval. Any attempt to fix other line issues now will result in unnecessary rework.
  • The existing pattern does not cover the required scope (see the far side), and any additional work would lead to scope creep to correct this error.

Sugar coated icebergs

Prototypes are great. They let the user see and feel what the final product will look like, either in printed or in online form.

They suck when the customer wants it next week because “it’s just a bit of wiring up to get it working”

And they can be dangerous. Ship that button without properly tested, or incomplete, code behind it and your software could crash and sink without trace.

If you want to always be finished, you need everything that the user can interact with to meet your quality standards. No unguarded exceptions, no raw data, no untested code. And if that means leaving that button out until it’s ready, do it. Or put in a bulletproof, well tested placeholder, like an email subscription to find your beta testers.

The user doesn’t know or care about all the mass under the surface that they can’t see, so don’t expose them to it. Keep the interface clean, simple and error free. Build up behind the scenes, behind feature toggles, and off production until you’re sure it’s safe.

The one thing worse than a missing feature is a horribly broken one. A user missing a feature may come back when the feature is ready. A user who’s experienced a broken feature won’t come back until they trust it.

Don’t lose your users’ trust.

development ux

Always be finished

I’ve been living on a building site for a while, at home and at work. The work at the office above ours was ambitious, chaotic, noisy, messy and overran. It was a challenging project, turning a “derilict” into a funky new office.

Home was a simpler proposition, a greenfield site, with a well tuned team putting up a batch of similar houses. Each house in the project was a clear finishing point. The work was completed on or near budget, although there have been many bugs in the finished product. Nothing to break the deal, but enough to be annoying, and a few that need serious attention before things get worse.

The most interesting thing for me however was complete the overall project looks. At each stage the customer perception is paramount, so roads and car parks are built and finished in places where in a few months they’ll be ripped up to put houses on because that’s the most central place to put the marketing suite so customers can see their house quicker.

And the perfectly manicured lawns at the show home will be ripped up to build a driveway for the garage. And the landscaped street gables get cut back to move the marketing suite. But at each stage there’s a clear “here’s what’s being built” and “here’s the rest” even when what looks complete is not the final vision.

The perception even extends to certain rules for residents to ensure consistent façades and a complete presentation, with no unsightly trade vans, for the entire site until the last one is sold.

When you build software, how finished do the “temporary” solutions look to the customer and the developers. Do they look hacked on, unreliable and in desperate need of a bug fix, or do they look finished and smooth to the end user, with a few backlog tickets describing what it really should do. No hint to users or competitors that something is about to change.

It’s not enough for everything you release to be complete and tested. If users can see the cracks, it will colour their impressions. Fix the snags and delight your users.

development ux

Wings of desire – future-proofing software architecture

(Note: this was originally posted on a since-archived company blog, so apologies for those who’ve read it before)

Architects are never quite sure how their buildings and common spaces are going to be used once real people move in. Just as software developers are never quite sure how their software is going to be used. Architects design openness into their designs in many ways, to allow spaces to be re-configured to a certain extend, and one important idea that they have used is leaving open areas unconstrained so that “desire lines” can form. These represent the most trodden paths, the favourite routes, across a space. Once these have settled down, months after the users have moved in, they can be formalised. Desire lines on grass are reinforced with gravel tracks. Desire lines in offices may be re-carpeted, or defined with furniture.

I’ve seen a few blogs talk about using desire lines to build web sites, using logs to determine which content was most used so that a re-design can highlight those areas or make them easier to use, and reinforce the way users are interacting with the site, but it struck me today when discussing new requirements with a client that desire lines are at the heart of many of the business processes that we model.

It is a rare occasion when a client comes to us with a fully formed idea of everything they want, so design and requirements capture is an intrinsic part of the development process, but there are many areas where the client doesn’t have an idea because no-one has tried it yet. There’s a new business process because they have a new class of user, or new laws to follow, or because the system and the business process it supports are being built together.

It’s tempting, as developers, to look for rigid rules, to find the underlying logic and find ways to make business rules concrete and algorithmic. It can also be the wrong thing to do. Have you ever had a customer or a user complain because the software does the wrong thing? When they have to work around the software to get the job done because the software is too inflexible? Not because the business process is inflexible (there’s not much we can do about red tape), but because the software enforced a business process that was incompatible with the best way to do the job.

Imagine a system where there is an approval process. There’s a screen, with a big “Approve” button on it. We know that  the requirements gathering process has identified that there are some business rules that need to be in place before approval. We know for sure that the Approver has to be a different user from the one who started the process, and in order to approve, the user has to add a comment for the audit trail. We believe there should be a time limit, but no-one knows what it should be, we know some other tasks need to be completed, but we’re not sure what. So don’t nail them down. Let the user add the comments to say that the time has elapsed. Let the audit record that the other tasks have been done. In 6 months time, the desire lines will be obvious. There will be a process. That’s when you update the screen.

We’re not mind readers or fortune tellers, so when we find ourselves looking at a problem we’re trying to nail down business rules that don’t quite make sense, or aren’t quite firm enough, maybe it’s time to step back and see if there’s a way to let users define their own desire lines where they get to decide how to get the job done, and once they understand the rules, we can always enforce them in the next version.


How to grok a new domain

One of the under appreciated aspects of software development is the number of different domains many of us work in over our careers, especially those working in consultancy. Software, generally, is straightforward, especially for the majority writing text boxes over databases. Not necessarily easy, but if you’re able to understand logical thought, and decomposition, picking up new languages and technologies is simply a matter of time.

The challenge is when things aren’t logical. When you have to use languages designed for humans, rather than machines, and when you have to understand processes that aren’t necessarily logical, or decomposed, and turn them into something a machine can understand.

Understanding the domain

The followers of domain driven design, and anyone who values use cases or user stories, will tell you that the first thing you have to understand is the user. What are they trying to do, and what nouns and verbs do they use to describe it?

These are the words you need to use. Whatever the system does, it should use those words to describe its state and to reflect that state back to the user.

Understanding the process

Software always models processes. Without understanding the processes, the software will model the wrong workflow, leading to a frustrating user experience. The real skill in learning these processes is understanding which are immutable and which are open to modification.

Once you start digging in, you’ll start to hear phrases like “we’ve always done it this way” or “we know that’s a bit clunky” or “here’s the workaround” which are big hints that there’s something to be improved.

Understanding the motivation

Key to understanding a new domain is understanding why. Why are people doing what they are doing – what is their goal? Why does the current software or process work the way it does? Why are you being asked to change it – what can you do to make things better?

It’s the most important question you can ask, and also the one most likely to be forgotten. Finding the right motivation for the software to exist is the key difference between successful and unsuccessful projects. One of the core tenets of agile is to keep checking that the software is meeting the needs of the users, gathering feedback and responding to it.

The logic of the illogical

For those of you that have never tried to turn the chaos of human language and rules into a logical digital narrative, I’d recommend listening to this explanation of timezones, and asking yourself how you’d go about learning all the rules and exceptions you’d need to be able to write this yourself.

development leadership

Embracing Agile Architecture

Good architecture can respond to new requirements.  It’s malleable where it needs to be.

A good leader trusts their team. And builds their team so they can trust them.

Architecture leads software, it defines the agility of the rest of the development, and it defines the fixed points that cannot be changed, that will always tend back to the initial conditions.

Get the architecture right. Decide as a team, and document the decisions as you go. Sometimes a decision is made on a proposition that is false. Sometimes the best solution yesterday is no longer the best solution today.

Everyone should be designing architecture of the system, and everyone should be reviewing it (pull requests on the written decision are great for capturing the discussion).

Your job as a leader is to make sure those discussions happen and are productive. Put the architecture decisions and the associated documentation next to the code, so they are as open for extensions and available for refactoring.

Democratise the architecture – get everyone to buy in, and you won’t come back to the project in 5 years and wonder when the monsters and hurricanes attacked.