Know the Domain (Shame on Me)

I write software that's tailored to solve problems for a particular domain, yet I don't know a lot about this domain. This lack of knowledge used to not really bother me, but now I find it very troubling. How can I be trying to solve problems when I don't truly, deeply understand the problems that need to be solved? It's pathetic and completely unacceptable. I need to know the domain for which I write software.

My previous performance reviews had objectives for learning about the industry that we write software for, and I've actually taken some steps to learn more. However, I've always treated this information as helpful and nice-to-have but not necessarily critical - and that's where I've been wrong. Domain knowledge is essential to creating powerful and wildly successful software, as it leads to a strong conceptual model and language that everyone on the team (not just developers) can use, as well as software that closely corresponds to this model and language. So I should be exerting as much effort towards learning about the problem domain as I have been towards learning new technologies, patterns, and practices.

What does the industry actually entail? What challenges is it facing and will be facing? Who are our customers? What problems do they have? What do they like about our software? What do they hate? How do they actually use our software (as opposed to how we think they use it)? What new features would they like to see? What's the roadmap and long-term vision for our software? I need to learn the answers to these questions and many more if I intend to design and implement innovative solutions for our customers. And as a test to determine whether I actually know the problem domain, I should be able to talk directly to our customers or potential customers using language that they understand, as well as explain how our software solves the problems they face.

Thus I'm trying to gain a deep understanding of the problem domain, and I'm curious to hear the ways in which I can learn more about the industry we're writing software for.

Refactoring Toward Deeper Insight

I'm a big proponent of constant, ruthless refactoring. However, I've only recently realized that I've completely overlooked a type of refactoring that's crucial to delivering a well-designed, customer-centric application. Until now I've been focusing on refactoring that mostly improves the technical quality of the code - the type of stuff largely captured in Martin Fowler's catalog of refactorings: renaming methods and classes to better reveal intent, removing duplication, extracting behavior so that classes and methods have a single reason to change, etc. However, reading Eric Evans's book Domain-Driven Design: Tackling Complexity in the Heart of Software has opened my eyes to another type of refactoring that's probably even more important: changing the code so that it reveals a richer, more insightful domain model that is closely aligned with the problem domain itself. This type of refactoring is known as refactoring toward deeper insight.

Refactoring toward deeper insight is not a substitute for technical refactoring, as both are absolutely needed. In his book Evans states that refactoring toward deeper insight:

"superimposes another level [of refactoring]: refactoring to a deeper model. Executing a refactoring based on domain insight often involves a series of micro-refactorings, but the motivation is not just the state of the code. Rather, the micro-refactorings provide convenient units of change towards a more insightful model. The goal is that not only can a developer understand what the code does; he or she can also understand why it does what it does and can relate that to the ongoing communication with the domain experts."

So refactoring toward deeper insight produces a powerful domain model whose benefits are obvious and immediately useful. That's why it's essential that this type of refactoring not be ignored. However, it requires a rigorous process Evans calls "knowledge crunching" - sorting through a bunch of information surrounding the problem domain to abstract out a set of concepts that best represent the most relevant aspects of the domain. This is more difficult to do than pure technical refactoring, thus Evans suggests three things to focus on when attempting refactoring toward deeper insight:

1. Live in the domain.
2. Keep looking at things a different way.
3. Maintain an unbroken dialog with domain experts.

Despite its additional effort and unfamiliarity to me, I fully intend to try more refactoring toward deeper insight. And of course, I'd love to hear others' experiences with this kind of refactoring and any suggestions they have.

At the End of the Day, Is It Always Me?

There are a number of qualities I look for in my manager/supervisor/boss - someone who is respectful, a great listener, passionate, technically competent, and willing to teach and mentor. However, the quality I most want in my manager is an unwavering willingness to support and defend me.

In his keynote at the Software Craftsmanship North America conference, Ken Auer mentioned that the fastest way for a manager to gain loyalty from his or her employees is to always choose the employee. Basically, at the end of the day, does the manager always side with you (the employee) or someone or something else (like management, your process, the customers, etc.)? A good manager never leaves any doubt about this question; he or she always sides with you. And my experiences have matched Ken's comment. I've been fiercely loyal to the managers that have supported and defended me, while losing trust and respect in those that haven't.

As a student worker in college, I had the task of walking over some daily fundraising totals to the university's cashier's office. Despite being incredibly simple, it became frustrating because I had to deal with a clerk on a power trip who would argue with me on a daily basis about some trivial matter that I now don't remember (but I am certain it was trivial). After once returning looking visibly frustrated, my boss asked me what was wrong. After explaining the problem, he immediately grabbed his jacket and notebook and went to the cashier's office. Thirty minutes later he returned and stated that I would no longer be having any more issues with this troublesome lady. And he was right; my seemingly simple task was now actually simple and carefree.

I was astonished that my boss would immediately go to such lengths to argue for me, the lowly student employee. I instantly developed a strong sense of respect and faithfulness to him, which would continue to grow as he continued to protect and defend his employees. I was then fortunate to have Jim as my manager, who also has this great quality in spades. And because of this, I'm willing to go to hell and back to get a tape backup that needs to be restored if he asked me to. I'd even write a COM app in VB 6 if he wanted.

Unfortunately, the only way to spot this quality is to experience it firsthand. At some point you'll be in a situation where your manager has to choose between you and someone or something else, and that's when you'll find out what kind of manager you have. But it's not a trait that you can identify in an interview or something like that. Nonetheless, it's essential to know where your manager stands: at the end of the day, is it always you?