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:

1. Not completely mindless
2. 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 or 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 reason 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.

The post The Renaissance of the Problem Domain as a First-Class Concern appeared first on DaedTech.