A Stakeholder’s Thoughts on Developers, Collaboration, and DDD
As my career has progressed I have gradually grown from a programmer into a person who uses collaboration and technology to solve business problems. Learning about Domain Driven Design was one of the most important steps I took in achieving this, because it taught me to focus on business problems and collaboration with non-technical people.
In this post you’ll see some insights that may help you to grow into a (better) leader and business problem solver. They come from a recent interview I gave to Sarah — a product owner and travel & holidays domain expert.
Sarah shares her thoughts on collaborating with developers, and provides insights into what she perceives as a good developer. I hope you find this information useful and are encouraged to spend more time learning about problem domains and business priorities.
If you do find this post useful you may also want to check out Practices, Principles and Patterns of Domain Driven Design. It combines business insights from non-technical people like Sarah, with technical practices like event sourcing, to help developers bridge the business and technical divide.Meet Sarah
Hi there. It’s true, I am non-technical. If you open me up and look inside, you will find that I am entirely made up of non-technical matter.
I work for a well known online travel agent where I manage content for a ludicrous amount of hotels. During my time here I have moved from data analysis, to client management and now to content management, so I have developed a good overview of the business and travel industry.
Say hi to Sarah I work with a lot of lovely people and depend heavily on good systems in order to carry out my content management tasks. This is mainly so that I can spend more time doing other far more interesting things like analysing data, filling product gaps, responding to demand, and acquiring new content — all to improve that thing we business people go crazy over: conversion. I do love a bit of conversion.
I also like hot weather, history, criminal psychology, luxurious hotels and driving. I dislike sharing food and people who don’t listen. I am really really bad at remembering plans. I often go for weeks with no plans, then realise I have triple booked myself. I live with daily fear that I am supposed to be somewhere else. Like right now.
How often do you interact with developers, and how much do you depend on them to achieve the goals of your job?
I interact with developers pretty much daily for business as usual processes and issues. For projects, I tend to interact mainly with project managers or account managers, its rare I would interact directly with a developer whilst the project is being carried out.
I do depend quite heavily on developers to help to provide answers, explanations and solutions for issues. I can’t really improve any technically based process without the input of developers. If I can’t do that, goals will either take longer to achieve or I would have to lower my expectations on what can be achieved, both of which kill my motivation.
Are you comfortable asking developers to explain a technical concept that you don’t understand? Do you have any memorable experiences, positive or negative, of doing so?
I’m only comfortable doing this with the developers that I have a good relationship with and who make an effort to be helpful and available.
Memorable experiences include being described the basics of an inverted index, using my very own set of comments from a previous conversation. I found that example very useful and often refer to it. I am a huge fan of pictures and diagrams to explain processes, so any session where diagrams are provided is massively helpful to me.
Using objects to explain things helps too, I once had databases explained to me using a pot of highlighter pens, which was extremely enlightening.
Often, when I’m trying to get an idea of a cradle to grave data process at work, I will be told fascinating stories about Sarah Flights and Sarah Hotel and Sarah Bedbank. Imagining things that are familiar to me or being able to actually see how things work (possibly using stationary) is really useful. I like to keep it simple and basic and I am not ashamed of this.
You started to touch on collaboration techniques in your last answer. What collaboration techniques do you think are the best when knowledge has to flow in both directions? i.e. you need to work with developers to teach them about your domain to create a shared model?
I would say that mapping out key systems and touch points are one of the best ways you can do this, perhaps on a whiteboard or on large sheets of paper. This not only helps me to organise my thinking and highlight gaps in my own knowledge, but it also shows very quickly where there is redundancy in the architecture.
It is really valuable for a developer to then be able to view the set up with a fresh pair of eyes and point out the processes that can be discarded or improved. Sessions like this also mean you can ask all the questions you want there and then, in an environment where you know you are not going to break anything and destroy the whole company.
Things going wrong is also an opportunity for developers to learn about the domain. Instead of writing tickets that get lost in Jira I find that providing demos is a great way of showing what happened, what should have happened, and what you would like to happen instead. I find this the most efficient way of collectively iterating on concepts; it not only enables developers to learn about the domain more quickly, but also results in the business reaching a solution much sooner.
A few weeks ago I had what I now refer to as a Post-it Party. This particular session was actually with a colleague, not a developer, but I found the concept extremely helpful and transferable.
A Post-it Party is probably best applied when you are working on something pretty big and game changing — in this case, we were trying to scope out a new content management system. You simply write each individual issue or requirement you can think of on a different post it note, and stick them all over the wall in an order that makes sense to you (your current set up, for example). You can use different colour notes to represent different things, perhaps levels of severity, or different systems.
Once you have put all of your notes on the wall, you move them around to try to solutionise the problem. You can draw arrows between the notes to show dependencies and annotate the whole diagram however you like. The thing I loved about this process was the flexibility to move the issues around to different areas and create a visual pattern that eventually begins to make sense.
I feel that this kind of process would be a great way of opening up a two-way conversation and getting the ideas and creativity flowing. I recently learned that this process is called Model Storming, however I would like to point out that a Post-it Party also includes pizza and ball games and is a thoroughly smashing day.
Have you ever worked on a project that suffered from ambiguous terminology where an explicit shared vocabulary (Ubiquitous Language) may have been beneficial?
Yes I have definitely suffered from ambiguous terminology during projects.
I would have to name telephony as the area where we’ve suffered the most from not using a ubiquitous language. A problem spanning many years, this revealed itself in full when we were rebuilding our booking system, which incorporates telephone number set up for our adverts. Here is how one of our meetings went:
PM: “Then they set up the DDI to go on top of the routing number”
Diplomatic Dev: checks documentation “Ok. So that bits the…TLI”
PM: “Yes.”
Me: “No.”
PM: “No?”
Me: “No. We assign the NGN to go on top of the routing number.”
PM: “Oh. Right, so where does the DDI go?”
Me: “The routing number is the DDI”
Diplomatic Dev: “Ok. So where does the Advertised Number go?”
Me: “That’s the NGN. It goes to the DDI”
Diplomatic Dev: “And the TLI?”
Me: “That’s the DDI”
PM: “And the Delivered To Number?”
Me: “Also the DDI”
Diplomatic Dev:Checks documentation “And what about the C number?”
You can see where its going.
We wasted a lot of time having this kind of conversation. In hindsight, it would have been much more efficient (and much nicer for Diplomatic Dev) to collate all of the terms and their meanings, and only use one set throughout our requirements.
Not using a ubiquitous language also resulted in a scary moment not too long ago, whilst I was enquiring with a developer if we could potentially strip out a whole layer of IDs from our current architecture. We were quite happily having a conversation about this, when he sent over an example of what the new code would consist of.
A little shiver went down my spine as I noticed that it contained a whole new ID that I didn’t recognise. In the space of a couple of seconds, I questioned everything I previously thought I had understood about these IDs, and my comprehension of all our other technical process whilst I was at it. It turned out that the developer simply had a different term for one of the IDs.
Eventually we rolled the whole conversation back a step or two until we were on the same page, and then everything was fine. Afterwards, we apologised to each other and had a little laugh about how silly and complicated things were. Perhaps I overreacted a little. But it did get me thinking that if we had genuinely gotten our wires crossed because of ambiguity, what catastrophe would have had to happen before we realised?
**Do you think it’s important to teach your developers which parts of the domain are most important (core domains) — where the business has a competitive advantage or generates the most revenue? **
I find that people tend to work best when they care about what they’re working on and why, so I cannot imagine collaborating on any project without teaching the core domains. These are the bits that will show you tangible results, so for me it’s the most exciting part and I like to share it.
This is also a very good way of building up a relationship between the business and developers because it provides an opportunity for that two-way communication flow to occur, which usually results in everybody feeling like they are on board and part of the fun.
During the process, its important to receive feedback and questions from developers so that you can find out how good a job you have done of explaining the domain. I also find that running through the core of the business helps me to realign my own thinking and gain clarity of mind — which is really important when you’re about to deep dive into a problem.
**Are there any other qualities that make it easier to work with developers? **
When I find myself in a technical drama situation and have had to recruit the help of a developer, I find it really useful to be presented with options. As a business person, its very easy to fall into the trap of wasting valuable time trying to solutionise your own problem using a set of bad processes that you have become used to.
Developers who challenge this method of thinking and go out of their way to truly understand the problem domain so they can give you new and fresh ideas, are a total godsend.
A developer who is quick to respond is a lifesaver. I am often pushed for time because I’m busy trying to deal with the consequences of a problem, where I often have to manage a lot of peoples expectations as well as provide updates to rest of the business. Having a developer who can pick up your problem quickly and give you either a temporary solution or provide a top level explanation and keep you informed is absolutely critical.
What are the 3 biggest changes you would make to improve the way software developers and business stakeholders interact?
- Have dedicated developers and more time actually talking to them and being in the same room. I really believe that direct communication is the best method and its important to be able to show developers what your problems are.
- If developers are outsourced, better communication within the business as to what the set up is and who does what. I spent a lot of time in the dark not really knowing who people were and what people worked on. Its crucial that the business explains the infrastructure that is in place to the stakeholders, so that everyone knows how to interact with each other and feels comfortable doing it.
- If there’s any sign of a divide between business and tech, get to the bottom of what is causing it and fix it.
Please can you share your overall of opinion of software developers in a few sentences?
They’re kind of cool, especially the ones who have a passion for working with other people to solve problems. This is a great quality because it achieves results quickly, and this motivates me to continuously improve the business.Conclusions
Many of Sarah’s insights align with the practices of DDD. In particular, the importance of developers, domain experts, and stakeholders spending meaningful time together. As Sarah implies; white board sessions, visualisation, and interactivity can be helpful for maximising these collaboration opportunities.
A key insight Sarah provides is the importance of understanding the core parts of business — its core domains. As she says, this is where tangible business-level improvements come from. If developers understand the core domains, they can take more motivation and pride from business successes.
A common problem developers face is when requirements dictate the solution. For example, the business stakeholder tells you to solve the problem how they think it should be solved. What Sarah shares in this post is that a good developer will challenge assumptions collaboratively to understand what the fundamental problem is before deciding how to solve it.
Whether you use DDD to help you or not, I hope Sarah’s insights inspire you to be more than just a coder — take an interest interest people, question assumptions, and have fun knowing that you are a person who can make a real difference to something important.
More than just a coder — you can be a key member of the team
credit: Ambro @ freedigitalphotos.net
feel free to ask Sarah further questions by leaving a comment