We have plenty of more or less formalized approaches to development that have become popular:

• Test-Driven Development (TDD) focuses on writing tests before the actual code.
• Acceptance Test-Driven Development and Behavior-Driven Development are incarnations of TDD that aim to involve non-technical team members in the process.
• Domain-Driven Design focuses on connecting code with the actual business context.
• Feature-Driven Development emphasizes workflow around coding to optimize for efficient deliverability.
• Object-Oriented Development is a classic that revolves around the architectural concepts of many modern (object-oriented) programming languages.

I could go on with this list, yet you get the point. We create formalized approaches to programming to help us focus on specific aspects of the process, be it code architecture, workflow, business context, etc.

A bold idea: How about Care-Driven Development?

Craft and Care in Development

I know, it sounds off. If you look at the list above, it’s pretty much technical. It’s about objects and classes, or tests. At worst, it’s about specific work items (features) and how they respond to business needs.

But care? This fluffy thing definitely doesn’t belong. Or does it?

An assumption: there’s no such thing as perfect code without a context.

We’d require a different level of security and reliability from software that sends a man to the moon than from just another business app built for just another corporation. We’d expect a different level of quality from a prototype that tries to gauge interest in a wild-ass idea than from an app that hundreds of thousands of customers rely on every day.

If we apply dirty hacks in a mission-critical system, it means that we don’t care. We don’t care if it might break; we just want that work item off our to-do list, as it is clearly not fun.

By the same token, when we needlessly overengineer a spike because we always deliver SOLID code, no matter what, it’s just as careless. After all, we don’t care enough about the context to keep the effort (and thus, costs) low.

If you try to build a mass-market, affordable car for emerging markets, you don’t aim for the engineering level of an E-class Mercedes. It would, after all, defeat the very purpose of affordability.

Why Are We Building That?

The role of care doesn’t end with the technical considerations, though. I argued before that an absolutely pivotal concern should be: Why are we building this in the first place?

“There is nothing so useless as doing efficiently that which should not be done at all.”

Peter Drucker

It actually doesn’t matter how much engineering prowess we invest into the process if we’re building a product or feature that customers neither need nor want. It is the ultimate waste.

And, as discussions between developers clearly show, the common attitude is to consider development largely in isolation, as in: since it is in the backlog, it has to add value. There’s little to no reflection that sometimes it would have been better altogether if developers had literally done nothing instead of building stuff.

In this context, care means that, as a developer, I want to build what actually matters. Or at least what I believe may matter, as ultimately there is no way of knowing upfront which feature will work and which won’t.

After all, most of the time, validation means invalidation. There’s no way to know up front, so we are doomed to build many things that ultimately won’t work.

Role of Care in Development

So what do I suggest as this fluffy idea of Care-Driven Development?

In the shortest: Giving a shit about the outcomes of our work.

The keyword here is “outcome.” It’s not only about whether the code is built and how it is built. It’s also about how it connects with the broader context, which goes all the way down to whether it provides any value to the ultimate customers.

Yes, it means caring about understanding product ownership enough to be able to tell a value-adding outcome from a non-value-adding one.

Yes, it means caring about design and UX to know how to build a thing in a more appealing/usable/accessible way.

Yet, it means caring about how the product delivers value and what drives traction, retention, and customer satisfaction.

Yes, it means caring about the bottom-line impact for an organization we’re a part of, both in terms of costs and revenues.

No, it doesn’t mean that I expect every developer to become a fantastic Frankenstein of all possible skillsets. Most of the time, we do have specialists in all those areas around us. And all it takes to learn about the outcomes is to ask away.

With a bit of luck, they do care as well, and they’d be more than happy to share.

Admittedly, in some organizations, especially larger ones, developers are very much disconnected from the actual value delivery. Yet, the fact that it’s harder to get some answers doesn’t mean they are any less valuable. In fact, that’s where care matters even more.

The Subtle Art of Giving a Shit

Here’s one thing to consider. As a developer, why are you doing what you’re doing?

Does it even matter whether a job, which, admittedly, is damn well-paid, provides something valuable to others? Or could you be developing swaths of code that would instantly be discarded, and it wouldn’t make a difference?

If the latter is true, and you’ve made it this far, then sorry for wasting your time. Also, it’s kinda sad, but hey, every industry has its fair share of folks who treat it as just a job.

However, if the outcome (not just output) of your work matters to you, then, well, you do care.

Now, what if you optimized your work for the best possible outcome, as measured by a wide array of parameters, from customer satisfaction to the bottom-line impact on your company?

It might mean less focus on coding a task at hand, but more on understanding the whys behind it. Or spending time on gauging feedback from users instead of knowing-it-all. Definitely, some technical trade-offs will end up different. To a degree, the work will look different.

Because you would care.

Care as a Core Value

I understand that doing Care-Driven Development in isolation may be a daunting task. Not unlike trying TDD in a big ball of mud of a code base, where no other developer cares (pun intended). And yet, we try such things all the time.

Alternatively, we find organizations more aligned with our desired work approach. I agree, there’s a lot of cynicism in many software companies, but there are more than enough of those that revolve around genuine value creation.

And yes, it’s easy for me to say “giving a shit pays off” since I lead a company where care is a shared value. In fact, if I were to point to a reason why we haven’t become irrelevant in a recent downturn, care would be on top of my list.

But think of it this way. If you were an aerospace industry enthusiast, would you rather work for Southwest or Ryanair? Hell, ask yourself the same question even if you couldn’t care less about aerospace.

Ultimately, both are budget airlines. One is a usual suspect when you read a management book, and they need an example of excellent customer care. The other is only half-jokingly labeled as a cargo airline. Yes, with you being the cargo.

The core difference? Care.

Sure, there is more to their respective cultures, yet, when you think about it, so many critical aspects either directly stem from or are correlated with care.

Care-Driven Development

In the spirit of simple definitions, Care-Driven Development is a way of developing software driven by an ultimate care for the outcomes.

• It encourages getting an understanding of the broad impact of developed code.
• It drives technical decisions.
• It necessarily asks for validating the outcome of development work.

It’s the art of giving a shit about how the output of our work affects others. No more, no less.