The Renaissance of the Problem Domain as a First-Class Concern
Hey, look at that — I’m writing a blog post again! Seriously, apologies for the lull, but, hey, life happens.
Enough of that, though. Let’s dive into some realio-trulio, software related content.
I Read an Interesting (Horrifying) Tale This Morning
Lately, instead of starting my day blearily looking at my phone and the emails that have trickled in while I slept, I’ve been starting each day with unstructured reading and chatting. I randomly read my feed, talk to people on Slack, watch a Youtube video, or take some research flight of fancy.
Anything goes as long as it’s:
- Not completely mindless
- Not directly related to work I’ll do
I can’t recommend this practice enough, especially for the self-employed set. It stimulates creativity and sort of gets all of the things that normally distract me out of the way.
But I digress. The real point of this mini-anecdote is to say that I read a blog post from Uncle Bob Martin this morning. It’s a compelling read, as his posts generally are, and it talks about the recent Boeing crashes.
Here’s something that jumped out at me, though, somewhat oblique to the narrative, and relatively mundane in an otherwise pretty grim tale.
Rather, programmers must [have] intimate knowledge of the domain they are programming in. If you are writing code for aviation, you’d better know a lot about the culture, disciplines, and practices of aviation.
And then, this, at the end:
We have to know the business domains we are coding for.
Huh.
The Fraught Relationship Between “Craft” and Domain Knowledge
This begs the question: are these “done-right” Boeing engineers programmers that happen to have aviation expertise, or are they aviation professionals that happen to program? If you find yourself saying, “both,” I’ll treat you to a witticism that I like from the agile world, designed as kryptonite to the project manager that proclaims all user stories top priority:
If everything is a priority, then nothing is, so I’ll choose for you.
And so it goes here. If you say that these Boeing software engineers should be both “programmer” and “aviation professional,” first and foremost, they’ll choose for you. And, which do you think they’ll choose. My guess is the “programmer” since, when they leave their jobs at Boeing in somewhere between 9 and 27 months to go program at a startup or whatever, they will cease to be “aviation professionals.”
Now, a big part of this story is, obviously, the domain transience of today’s software developer. But another part is the focus on “craft.”
My opinion on the craft guild metaphor is no secret to long time readers. We’ve taken it too far.
Software is neither a craft in the practical nor the ontological sense. We don’t build software so that our customers might enjoy the aesthetic qualities of code well written, nor do we form local labor cartels for collective bargaining and go sleep in software engineers’ attics at age 11 that we might learn from them.
Software-as-a-craft is really a vibe. It says, “I care about the quality of the code that I write.”
And caring about that is inarguably a good thing. But a hanger-on to that vibe tends to come in the form of “I care about the quality of the code that I write first and foremost above other concerns.”
Other concerns like, say, what problem domain you’re working in.
“I can do excellent work in any industry or domain, if I abide by clean code principles and care about my work.”
The Bigger Picture: Are We Categorizing Software Work in a Fundamentally Flawed Way?
Of course, a focus on craft is just one source of this attitude — the first one that came to mind (doubtless because I was reading Uncle Bob’s blog).
It can also happen with hacker culture or the startup scene.
“Whatever, man, airplanes or air conditioners, jetting websites or betting websites, I just sling teh codez.”
Regardless of our attitude toward writing the software, our relationship with it defines how we identify in the corporate world. We are software {engineers,developers,whatevers} first, and everything else secondarily.
This was, no doubt, more reasonable decades ago when professional software people numbered far fewer. But now, there are something like 20 million software developers, so segmentation naturally had to emerge.
But what does this look like? Well:
- React developer
- Embedded engineer
- Full-stack web developer
- .NET programmer
Rather than:
- Aviation programmer
- E-commerce programmer
- Sports gambling programmer
As a collective industry (whose justifiability I might increasingly debate), we haven’t specialized by customer, domain, vertical, or anything else externally understandable. Instead, we took our navel-gazing focus on the discipline itself, and doubled down on it over and over again, by specializing in our own tools.
This inside baseball form of specialization is so ill-suited — so opaque — that an entire industry (recruiting) has emerged to do nothing but help laypeople understand what we do. Don’t quite believe it? Imagine telling your grandparents that you’re a “react developer” and then imagine if that conversation wouldn’t go better if you’d brought a recruiter along to translate.
But Other Disciplines Stretch Across Domains!
At this point, I imagine you might have a predictable and understandable counterpoint. By implication, I’m demanding that software development, as a vocation, behave differently than, say architects, mechanical engineers, or even human resources. Aren’t we just following those well-worn tracks toward a pattern?
Well, yes. And that’s the crux of the problem, because software development is unprecedented.
- Have any of those other vocations grown exponentially in a short amount of time?
- Do any of them utterly dominate modern commerce?
- Are they so intensely generalized with so few educational/certification barriers to entry?
I could go on, but hopefully you get the idea. We’re applying historical precedent to the unprecedented, and I think it’s time that we revisit whether that makes sense.
Architects design buildings, so you could sub-group them by the sorts of buildings they design. But sub-dividing them by who eventually occupies the building doesn’t make sense, and subdividing them by what sorts of software and what kinds of pencils they use is utterly ridiculous.
And, if you start to look at disciplines that have withstood the test of time, you’ll see that they balance the discipline with the beneficiary. For instance, all lawyers pursue common education and certification, but they then market and categorize their services in the language of their clients:
- Divorce attorneys help people get divorced.
- Criminal defense attorneys help people mount criminal defenses.
- Patent attorneys help — alright, you get the idea.
Notice that they don’t bill themselves as “Plessy v Ferguson Attorney” and then leave it to you to figure out whether that means they can help you with a racial profiling civil rights case.
I’d Like to See a Rise in Picking a Problem Domain
If you were hoping that I had some grand plan to remedy all of this, then I’m going to disappoint you. I’m aiming more for “food for thought” with all of this. I don’t have the script for redefining software specialties, nor a sufficiently large soapbox that it would work if I did.
But I will say that I’d like to see a de-emphasis on specialty by programming skills/tools/techs, and a renaissance of a focus on domain. Like Uncle Bob, I think this would make for better software, more fit for purpose.
But I also think it would help usher in the Developer Hegemony vision.
One of the reasons that software developers are such afterthoughts in the software development decisions companies make is that those companies heap 7 layers of management atop us. Why? Because we can’t be bothered to learn domains, drifting instead from codebase to codebase, utterly abdicating purpose and context to those earning more money.
Programming is so dominant — so ubiquitous now — that I think a better model might be the iconic “proficient with Microsoft Excel.” In other words, there aren’t really people that go from company to company saying, “whatever man, I just do Excel.” Instead, they just quietly use Excel to make them better at their actual job.
As I’ve tried to describe with this idea of the “efficiencer”, the real, core value prop of software development is time savings through automation. Imagine how efficient we might become in that if we picked a vertical/domain and learned it, focused on it, and became expert in it, rather than just wandering around tweaking ORMs for different companies.
We’d get better at niching and specializing, and we’d elevate ourselves into important decision making roles. And, to Uncle Bob’s point, this increased agency might just position us to impact the world for the better in powerful and gravely important ways.
Hi Erik, I think at least part of the current disenchantment with the tech industry among programmers could be solved by settings things up this way (problem domain specialists). Actually, I was reading a Wired article about this issue, and the author’s sentiment seems to converge: “We’re like a carpenter who spent so long perfecting his tools that he forgot to build the church.” https://www.wired.com/story/why-we-love-tech-defense-difficult-industry/ Suddenly, we had so many things we could do, that never once did we stopped whether we should or how. Coders who care about the consumer problem they are trying to solve will probably be… Read more »
“When Yahoo! still deserved its exclamation point…” Awesome.
It’s nice to see some people trying to steer the battleship in this direction. I’d love to see a world where we, as software developers, are regarded as experts, instead of laboring weirdos who can be tricked out of their market value with a simple, gamified website like “coderduels.com” or whatever.
Another piece to this is the fact that clients typically don’t know what they want.It just doesn’t work to simply build whatever the client asks for. An agile approach — build what they ask for, let them see working software, and iterate until you get to what they actually need — can help. But in my experience the best approach is for the developer themselves to say “hang on — what actual problem are you trying to solve?”. Taking this approach — understanding the business need and solving it (which might end up not even involving code) — does require… Read more »
Good point about agile as an (imperfect) attempt to bridge the gap. But if the first thing you ask is “how,” that’s no good. “What” is a little better, but “why” is the best. I’d like to see more of us get there.
I think you touch on a deep, yet very much ignored issue in the tech industry. I say this as a so-called domain programmer (I don’t like the term ‘domain’), working for the same non-tech company for 20 some years working directly with users of my software on a daily basis. I have quite a lot to say on the topic but not much time ATM, so just 2 quick questions for now. 1) There is quite a developed body of techniques that fall under ‘Domain Driven Design’. There are also older techniques that go under names like Participatory Design,… Read more »
Good questions, both. I’m going to log them as reader questions to address here in the near future. I don’t think I could really address either one in any blog comment of reasonable length.
I think the Games Industry is already going this way.
I feel like It much more common for someone to be a “Graphics Programmer”, “Ui Programmer” or “Gameplay Programmer” than a being linked to a specific tool.
just a feeling though, no hard data.
That strikes true with me. I feel like “game developer” is a term I hear over and over, whereas this is not the case with other domains. I have very little insight into that line of work, however, so I’m not positive, but, like you, it feels right to me.
I think a similar problem also exists on the management side where domain specific knowledge is often not necessary either. Specialization into an additional domain of knowledge probably has a lot higher expected value than learning yet another framework or technology – once you’ve proven that you are able to acquire new technological skills it may be a better idea to get some additional knowledge elsewhere, especially if that knowledge isn’t as “perishable”. Something you should naturally pick up as a self-employed person for example is things like Accounting and basic understanding of taxation. There probably are a lot of… Read more »
I completely agree that there’s diminishing returns to learning additional stacks or frameworks that could be better spent learning business practices.
Yeah the question is how do you acquire those skills efficiently and be able to also prove them. Getting an MBA is probably overkill.
I agree with your point, though I’m not always sure the market is ready for it. Or more specifically, “my” market. I live in belgium, which is a small country that is even split up into two smaller communities (Dutch and French speaking). This leads to more or less separate economies which are tiny compared to US norms. Specializing in a vertical could mean limiting yourself to just a handful of companies, unless you can go 100% remote and work for foreign companies. There might be a way in between? Specializing in a broader technical skill. Instead of being a… Read more »
I think the challenge with going from, say “I’m a react developer” to “I’m a front end developer” or “I make client side code more maintainable” is that you’re still in a situation where your buyers don’t understand or care about what you do, so they delegate the decision about employing/hiring you to your peers: the developers at their company. It just continues, I’d think, to look like generalist pseudo-employment. There are obviously counter-examples, like “Troy Hunt, Security Specialist.” But I think that’s tough to do for the most part. If I’m an executive, I have no idea if I… Read more »
I’m worried that one is just playing semantics games here which kinda smells like title inflation. For example, I’m sort of an open source database specialist, which means I know my way around MySQL, PostgreSQL, MongoDB and a few other things, with a focus an stability and recoverability (is that a word)? I could brand that as for example a “Business Continuity Consultant”, since a lot of the work around backup and recovery focuses on that aspect which also ties into risk management in general. But it does feel kinda convoluted, like calling the Janitor / Custodian a Facility Manager…
I think “title inflation” is a uniquely salaried concept. If you’re a free agent, the only thing that matters about a title is “does it fill my pipeline with business?”