I’m kicking off a new series of blog posts based on the Seven Strategies sections in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. The next seven blog posts will each be based on a different strategy from the section in my book called on Seven Strategies for Product Owners. You can also see the original blog post here: https://tobeagile.com/2013/07/16/seven-strategies-for-product-owners/.
SME stands for subject matter expert, the people who understand the domain that we’re building software within. These people have specialized knowledge and we want to find ways to incorporate that knowledge into the software we’re building.
Understanding a domain is often the first step in being able to build something useful for it. This is really what the analysis phase is all about. We do analysis to get familiar with the domain, understand the terminology and be able to represent the domain accurately in our object model.
Subject matter experts are usually not software developers but I still want a subject matter expert to get a good sense of what my code does just by reading it because I express my code in the domain model as much as possible using names that represent the concepts within the domain so even though a subject matter experts may not understand a computer language they should be able to glean the key things that my code is doing just by looking at it.
The most evolved people are self-directed, and I find that the most advanced software development teams are also self-directed. Developers are not necessarily subject matter experts in the area that they’re building software in but given time we almost always rise to the occasion and become domain experts after writing code in that domain for a while. When you work in a domain for years you get quite familiar with it. I know teams that understand the products so well that they take on the role of product owner themselves. This is not something for beginning teams or even many long-standing teams, but sometimes a team will just click, and they become the best representatives of their users.
This doesn’t always happen with teams but when it does it can be ideal because then the customer is fully represented by the development team. This also tightens the loop between what we build and the impact it has. Seeing how our code impacts other people can be empowering and when developers get a taste of how the work that they do can positively affect other people’s lives, then they can get very excited and often become much more engaged.
As developers, we can’t help learning about the domain that we work in. I worked in a huge range of domains as a software developer over the last three decades. I know about such diverse things is image processing and video compression, boat auto-piloting, wholesale bank accounting, and dozens upon dozens of other domains.
One of the things I love about being a software developer is that I get to constantly learn about new things and new approaches to problem-solving. Each domain has its own unique perspective and by learning about that domain, I often find that some of the concepts are transferable to new domains that I’m working in.
Being a software developer is like being a model builder. The models that we build are temporal models, they model behavior of a system. The model is only good if it’s accurate and what we model comes from a deep understanding of the subject matter that were working in. The more we understand the domain the more accurately we can model it.
Previous Post: « Why Practice 1: Say What, Why, and for Whom Before How
Next Post: Use Development for Discovery »