Language is Everything
In my first article in this series I outlined the foundations of my personal software development philosophy, how I thought the two principal pillars that supported it were language and constraint. In this second part I’d like to start to explore the first of those pillars, language and how it lies at the heart of all development.
When someone talks of programming and language the first thought is often Java, C#, Haskell, Ruby, C++ or any of the countless other languages that make up the development landscape. But this is a very limited technical focus on the role language plays in software.
Before we can write a line of code you need to have a clear explanation and understanding of what you’re being asked to build, you need to understand the context it exists in and you need to translate those concepts and ideas into code that clearly expresses it’s meaning agnostic of the language it’s written in.
And can it be done by Tuesday last week please?.
So without clear language weaving a thread, binding everything together, you find yourself in a constant battle of confusion, misunderstanding, and wasted effort.
Language of the Domain
In Eric Evans classic Domain Driven Design he talks about ubiquitous language. This is the concept that every Domain (the sphere of knowledge that the software operates in) has a language. In that language, words, phrases, and terminology come packed with weight and meaning and that by understanding these abstract concepts and aligning our software with them, we end up with clearer code that more fully expresses the requirements of the business domain.
What this means to me is that language matters.
by really caring about what people around you are saying and really digging into what they mean (known as knowledge crunching) you get multiple benefits. Firstly you reduce the burden of translation between what you are being asked to do and the code being produced, secondly you increase the clarity of the conversation people and start to really think about what they are saying and what they mean.
By making people discuss the meaning of things it will often shed light onto the discrepancies in common terms or turns of phrase. This isn’t exclusively between the development teams and the rest of the business, I’ve seen many occasions where two subject matter experts will find they have subtly different understandings of the same concept.
By discussing and dissecting the everyday language of those around you and developing a clear lexicon of meaning for your business, you normalise in depth discussion on topics as well as reduce the cognitive burden of constant translation thus minimising the risk of misunderstanding.
‘When they say this, they really mean that. Except whatshischops in accounts, who knows what the hell they’re on about!’.
The uncovering of ubiquitous language is not just about uncovering these areas of miscommunication, it’s getting people to start to care about all communication. Breaking out of own language bubbles and trying to understand the people around us, engenders a culture of inquisitiveness and discussion not silos and bunkers.
Application
So how do we grow this culture? What techniques and steps can we use?
Below I’m going to outline some ways I’ve worked with my team to help promote this understanding.
A lot of these will be familiar to anyone with a passing knowledge of Agile development and it may be tempting to dismiss these as nothing new, but the devil is in the detail.
I love the quote ‘they’ve got 10 years experience, unfortunately it’s the same year repeated 10 times’, it sums up that just repeating the same thing without self-reflection does not improvement make.
The same rule applies with any of the techniques listed below. Writing user stories does not confer magical benefits, researching users stories, striving to learn how to do them well and anchoring them with other techniques in a coherent philosophy that gives them purpose does.
It’s not just about the code
Try to be interested in the domain you work in. Simple to say a lot of work to do.
The company I work for currently is primarily based in the medical domain, this is a rich and dizzying world with a complex language and deep context.
I’m not a doctor or a Pharmacist, I’m not going to be prescribing anyone medication anytime soon (thankfully) but in order to create software to better serve the clinicians that use it I’ve had to familiarise myself with its nomenclature and concepts.
The software we build does not live in an independent bubble. We may know the occult meanings of memory allocation but if we are to make anything of value to a user then we need to care about what we are building not just how. We need to be interested in the words our users choose and what they mean and do our best to understand them.
Tell Me A (User) Story
This may seem obvious, user stories are one of the fundamental techniques of the Agile process, but because they are so commonplace they are simultaneously the most significant and the most overlooked of all of the Agile methods.
User stories are a technique that uses both of the pillars of the development philosophy I’m outlining, because they are an example of language applied under certain constraints in order to define clear meaning.
User stories are often described as ‘a placeholder for a conversation’ but the quality of that conversation is dependant on the work that has gone into it. If ‘conversation’ is limited to an all hands on deck refinement session every two weeks, where stories are more like placeholders for tasks that you’ve already implemented in your head, then you’ve lost most of the value. If however user stories are born from a fertile ground of a rich shared language and a culture of collaboration and discussion then the result is very different.
The reason this is important is because capturing requirements are some of the hardest things in software development (after naming things and the other one everyone has to look up when they paraphrase that quote).
Much like writing tests first in TDD is more than just ‘test coverage’, good stories are more about defining the question is you are trying to answer. Writing a user story is about the discussion of what you want, not about how you’re going to achieve it.
In one of my very first jobs a very inexperienced sales rep actually wrote a client contract that had the phrase ‘and so on’ in the paragraph on support. Those 3 words cost the company thousands as the client used them to leverage all sorts of extra features. That was a terrible (and memorable) mistake to make but I’ve seen many a User Stories played with a similar lack of forethought and detail with similar results.
A user story is as much about knowing where to stop as it about knowing where to start.
There’s something about the process of really defining and refining a story that can condense the essence of the discussion into very few words. Words that carry a lot of meaning, something that always feels missing if the work isn’t done upfront.
Horizontal Communication
The more experience I gain managing teams the more I realise that the more you create a structure where communication has to flow through you in a hierarchical fashion the more problems you have (and the more meetings you have to sit in). While hierarchies have their uses they should not get in the way of the communication of the team.
The aim of leading a team instead, I think, is to encourage and facilitate an environment of horizontal communication.
Making sure that the team has the right forums where they feel free to communicate (team only slack channels for instance) and then encouraging everyone to use them to talk to each other (not just you).
Making sure there are clear and visible lines for the team to talk out to other teams and the rest of the business to talk back and then making sure those channels are used.
Finally there needs to be clear purpose, the team need to know what their priorities are and support each other towards achieving them.
Everyone needs a Studdle
Agile has a lot of terrible names for good ideas (grooming anyone?) and ‘Studdle’ is one of them, it’s short for Story Huddle and it was first introduced to me by a friend and colleague Eldon Ferran De Pol who was in turn introduced to it many years ago while working for BT.
I’ve done a bit of looking and have found some similar references to things like ‘dev huddle’ but they’re not quite the same.
Basically whenever a new piece of work is pulled into a sprint a Studdle is called. The story is discussed, we make sure it’s understood and then we have a discussion on the different potential approaches for development and decide on a general direction, then the pair or group who have picked up the story begin with the teams blessing.
What I like about this is that it promotes group ownership of a decision, if an approach is agreed with the input of the wider team (even if it’s only a subset) then everyone feels included and has buy-in on the decision and a personal investment on the outcome.
Instead of the story that Jane and Eric picked up last week that I have no clue about, it’s that story that we all discussed last week (you know the one where decided that we use a document store instead of a relational database).
Even if you suggest something and it’s decided against, you’re involved in that decision and it happens at the beginning of the process not half way through or at the end.
What I’ve also found is that if a team works this way regularly then, even if the whole team aren’t present for whatever reason, they are more likely to trust the decisions made by other parts of the team because they’re used to the way everyone thinks.
Pairing/Mobbing
We have a rule on the team ‘You never walk alone’ which means that no one should ever pick up a piece of work and the first time you have a conversation about it is at the point it’s being reviewed or accepted.
We always aim to work with at least one other person on any story for lots of reasons, improved code quality, better understanding of the code base, skill sharing, but primarily it’s because problems are solved faster if you have someone next to you sharing the pain.
Working with someone in a pairing situation can be hard and mobbing is not the answer to every problem, but like the Studdle, a team that works together like this starts to build a common culture of understanding and shared language. Shorthand develops and the communication speeds up because we’re so used to sharing our thoughts and musings.
Conclusion
Software is language, from the first conversation down to the last commit. It is more than just a technical domain, all software exists in a context, to service a need and writing beautifully crafted code means nothing if it’s meeting the wrong need.
By Concentrating on defining the ubiquitous language of the Domain you work in, encouraging a culture where discussion and debate are the norm and then using that all to feed into well refined User Stories reduces the frustration and waste of mis-communication and wasted effort and at the same time makes the job more fun.
Language is your primary tool, learn to use it well.
