Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: software craftsmanship

  • Care-Driven Development: The Art of Giving a Shit

    Care-Driven Development: The Art of Giving a Shit

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

    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.

    care transparency autonomy safety trust respect fairness quality
    Lunar Logic shared values

    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.

  • Code Better or Code Less?

    An interesting discussion (that might have happened):

    I would rather students apply their effort to writing better code than to writing better comments.

    ~ Bob Martin

    But…

    I would rather students apply their efforts to writing less code than writing “better” code.

    ~ Bob Marshall

    Because…

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

    ~ Peter Drucker

    Having read this, one realization is that better code often means less code. I don’t think about lines of code exactly, or something similarly stupid, but in terms of meaningful code. However, argument for less code isn’t about making code as compact as possible, avoid redundancy, etc.

    The argument is about not writing code at all whenever reasonable or possible.

    Should we focus on deciding what should and what should not built instead of polishing our software development craft then?

    Yes and no.

    Yeah, I know. Exactly the kind of answer you expected, isn’t it? Anyway, you can’t answer this question meaningfully without a context.

    Better code

    One perspective is the one of a developer. The developer in almost every medium-to-big organization, and in quite a lot of small ones too, is pretty much disconnected with product management/product ownership part of a project. It means that they have very little-to-no knowledge what actually should be built.

    Of course being a developer I can, and should, share my concerns about usefulness of building specific features but it’s unlikely I have enough information to judge such situations correctly in many cases. By the way, even when I’m right and this darn feature shouldn’t be built odds are that it’ll be built anyway because a client says so. Sounds stupid? Sure, it does! Does it make the client change their minds? Not very often.

    If you’ve ever worked on one of those big contracts where everything is (allegedly) specified upfront and no one on a client’s side is willing to change anything because of internal politics, you exactly know what I’m talking about. If you haven’t, well, damn you, you lucky bastard.

    So it might be a great idea not to build a feature but developers either don’t have enough knowledge to be aware of the fact or aren’t allowed to skip the feature anyway. In this case a better thing to do is to focus on building better code, not less code, because one can hardly say what meaningful less is.

    Less code

    The other perspective is the one of product management folks, however this specific role is called in your org. For them, their first and main focus should be on building less code. Yes, product owners, product managers, etc. Yes, less code. And yes, I do know they don’t write code. It still should be their main goal.

    You see, this is the place where meaningful decisions about not building features can be made. Product folks should know what adds value and what doesn’t. What’s more, they are usually better suited to start such discussions with clients, whenever needed. After all, it is so common that clients want, and pay for, unnecessary features and useless code.

    Organizational-wise you get more value, or less waste, focusing on building less code. Given that you’re free to work on both: better code and less code across the organization, it would likely be wiser to choose the latter. At the same time efficiency of your efforts depends much on the part of the organization you work with and, locally, it may be a much better choice to focus quality of code and not quantity of code as an issue to tackle.

    So if I could choose what kind of superhero posters are in rooms of my people I’d go with Peter Drucker for product folks and Bob Martin for developers.