DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
What's in store for DevOps in 2023? Find out today at 11 am ET in our "DZone 2023 Preview: DevOps Edition!"
Last chance to join

Be The SME

Who ya gonna call?

David Bernstein user avatar by
David Bernstein
CORE ·
Jan. 11, 19 · Opinion
Like (3)
Save
Tweet
Share
9.08K Views

Join the DZone community and get the full member experience.

Join For Free

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 .

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.

Software development

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • What Was the Question Again, ChatGPT?
  • DZone's Article Submission Guidelines
  • 7 Awesome Libraries for Java Unit and Integration Testing
  • What Is a Kubernetes CI/CD Pipeline?

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: