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.