On passion

One of my favorite bloggers, JP Boodhoo, has a little saying he puts at the end of every post:

Develop with passion!

I’ve only met JP once, and it was quite obvious from that meeting that passion is somewhat of a mantra for him.  It’s also something the best career counselor offered me years ago: “Find what you’re passionate about, and do that”.  When it comes to passion and programming professionally, I’ve seen two types of passion:

  • Passion for the craft
  • Passion for the domain

I’ve met far too many programmers that have passion, but only for the craft.  When the business would ask for some feature, their passion would lead to a technically interesting solution, but one that may or may not have solved the original problem.  This could be solved with deeper analysis of course, but what would lead that developer towards deeper analysis?  What motivates them to do so?  If all the developer is looking for is technical success, they will only reluctantly care about the domain problem, and only enough to get back to the technical problems.

We’ve all been guilty of this at one time or another.  Twisting requirements, hedging estimates to make a fun technical solution turn into a no-brainer business decision.  We’re doing a great disservice to our employers with these actions.  I believe this strong motivation comes from a lack of passion for the domain.

One pattern I’ve started to notice lately is that continued success requires passion.  Without passion comes little sustained success.  Short-term success may come by accident, but it’s far easier to be unlucky in success than it is lucky.

When we apply our passion, we can’t put all of our eggs in the technical basket.  Domain-driven design talks quite a bit about the Ubiquitous Language, and how it is important for developers and domain experts to share the same language.  This language needs to come from the domain, not technical patterns and such.  Without passion for the domain, our organization will never achieve complete success.

When we’re in conversations with the business analysts about specific stories, working through the motivation behind the story, passion for the domain creates a two-way conversation.  Otherwise, it’s two people speaking different languages, trying and failing to translate in and out of technical mumbo-jumbo. “So you want to use an ESB for that?” “All I want is to not have to work these orders manually” “So you want an ERP system?” “What?”

Eventually the business analyst caves to technical demands, hoping that they solve the business problem at hand.  Since they aren’t the technical expert, the BA puts their trust in the developer.  Without passion for the domain, their trust is truly misplaced.

I truly believe it is a developer’s job to bridge the gap between technology and business.  Success in bridging this gap requires both passion for the craft and passion for the domain.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Misc. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • You hit the nail on the head here Jimmy.

    This is a very important concept to grasp, especially when doing DDD. That being said, this is also a very hard concept for most developers to use properly. Too often are we taught strictly about the technical domain and how to get said feature to work using the technical toolset, with little or no emphasis on domain modeling.

    I hope that more companies realize how important this skill is to creating a successful application and domain.

  • Sing it Jimmy!!!

    This a a skill set I feel many developers lack. The ability to abstract concepts of the technical aspects to higher level concepts that promote fluid knowledge transfer towards a domain model.

    Soft skills are in high demand and what will transcend the knowledge worker of the future from the technician of today.

  • I completely agree. I have had this theory for a while that our main responsibility as software developers is to disambiguate requirements, and how can you disambiguate requirements if you don’t understand their domain context and the motivation of the project sponsors? If a developer cannot effectively disambiguate requirements, then I believe that they are not an effective software developer, no matter how skilled they are at any particular technology or methodology.

  • Completely agree. Unfortunately I’ve met very few developers who are interested in doing the analysis or design needed to create good domain models, makes the ones who can do it very valuable.

  • Good point! Domain passion is so much harder to maintain that it’s easy to lose sight of it. Passion feeds passion, which may be part of the problem. It’s far easier to share passion about the technical side of your work because there is a broader community you can connect with. Connecting with a domain community that knows enough about the technical stuff to understand what you are talking about is nigh impossible.

  • @Jacob

    It’s tough to find a domain community, they largely don’t exist. However, Evans recommends in his DDD book, talking with the domain experts, reading books and just plain doing research.

  • Agree, “passion for the domain” as you call it is incredibly important. But do you see the two as mutually exclusive? Can you not have a passion for *both*? :)

  • “It’s far easier to share passion about the technical side of your work because there is a broader community you can connect with.”

    Agreed but I find I’ve gone the other way, the latest open-source or MS tool excites me far less than creating a nice little domain model that fits the problem domain and elegantly handles all required behavior.

  • @Frederik

    Definitely not mutually exclusive. I see that total success needs both.

  • Agreed. The most successfull are the ones that can do both.

  • Jimmy – I’ve believed the same thing for a long time, but have never been able to articulate it as clearly as you have in this post – you definitely have a gift for that.

    For me personally, my willingness to really take the time to become a student my employer’s / customer’s domain and understand their business problems has made all the difference in my career. I’ve almost never been the strongest software engineer on my team – a trend that has greatly accelerated as of late. However, I’ve realized I do not fully succeed on projects until I understand the domain as well as (or better than) the project stakeholders / subject matter experts. This sounds like a pretty tall order, but as they say, “That’s why we get paid the big bucks”…