Where are the domain experts?
August 11, 2016
A couple of weeks ago I made a comment to my team at work which I think a couple took harshly, but I believe it is true, and an indication of a deeper problem.
I said “All of the really smart people at this company move to the ‘infrastructure’ teams within a few years, which means we have only new, untrained people writing the real software.”
Today, on a flight back home from vacation in Oslo, I was reading Domain-Driven Design by Eric Evans, and once again I found myself taken aback by how precisely this book has described my work place–and not in a good way!
Scarce, highly skilled developers tend to gravitate to technical infrastructure or neatly defined domain problems that can be understood without specialized domain knowledge.
He goes on to say (emphasis mine):
Such parts of the system seem interesting to computer scientists, and are perceived to build transferable professional skills and provide better resume (CV) material. The specialized core, that part of the model that really differentiates the application and makes it a business asset, typically ends up being put together by less skilled developers who work with DBAs to create a data schema and then code feature-by-feature without drawing on any conceptual power in the model at all.
Wow. How precisely this describes my experience at work!
As with any project, we have a core set of database tables which describe our core customers and their products. These tables are constantly being augmented with additional tables (so that we don’t clutter the core tables–that much is good, I guess!). Need to track a new customer state? Add a new table! Need to catalog a new product feature? Add a new table! Nobody has any idea what others are doing with the core data model, in part because all of the people working on the core data model haven’t been fully initiated. There is no “master plan”–there’s just everybody’s corner of the project. And the vast majority of people working on the project are relatively new to the company. And by all appearances, they are largely new to data modeling in general.
Meanwhile, in the office building 10 minutes down the street, we have a large number of people who have been at the company 4 years or more, and never touch the core data model, but instead spend their time implementing better map-reduce implementations, optimizing git, or writing frameworks.
The week before I went on vacation, I was offered a new position at work. It would be one of the more ‘infrastructure’ type jobs. I was excited at the opportunity. It’s right up my alley! It’s an area I’ve been working closely with, making me the most natural fit for the position. The responsibilities would look great on my CV. It would put me in a position of higher visibility, which might be a boost for promotion opportunities.
But, just as I’m becoming a domain expert in the core business, I’ll be moving to work on peripheral infrastructure, leaving the core business to my replacement, who hasn’t even been hired yet!
Where are the domain experts? I’ll be sitting in the other office down the street… writing frameworks.
Adventures in DevOps 156: Where DevOps and ML Meet
Hosts of the Adventures in ML podcast join us to talk about the intersection of DevOps and ML.
Adventures in DevOps 153: Game Development With Dori Exterman
Dori Exterman, CTO at IncrediBuild, joins us to talk about DevOps in the gaming industry.
Improve your software delivery