This post originally appeared on jhall.io.
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.
Turn VM off and give my money back
Rafal Pienkowski -
Domain-Driven Design - The Factory in PHP
Life Beyond Distributed Transactions: An Apostate's Implementation - Relational Resources
Jimmy Bogard -
Effortless Real-time GraphQL API with serverless business logic running in any cloud
Vladimir Novick -