> While it would be ideal if all the software devs writing say a General Ledger application were accountants, the reality is that will not be the case.
I don't think this is necessary at all. However, to do a good job here, it's critical that the people building the software understand the principles of how the domain works and how people interact with it.
To take this literal example: I'm not an accountant or bookkeeper but I've spent 15 years of my career working with people in this domain. Even when I encounter a new part of the domain I'm not familiar with, I find it easy to put together the need from my existing knowledge and figure out what we need to do.
Take an example where I didn't invest in understanding a (financial) domain: my team inherited a report generation script that a founder was running for Finance. Initially, we just tried to expand it to handle more transaction items. Because we didn't understand how this report was being used, we skipped issues, caused issues when we changed things elsewhere, etc. Our Finance team was pissed because we were making their lives harder with our total lack of understanding. The answer? Spend time with the Finance team making sure every engineer understood what this report contained, what it was being used for, why it was important.
> In a software world dominated by technical requirements, how to determine and model functional requirements in an external domain can be what makes a programmer a great one.
I agree here, I just think that this understanding needs to go a little deeper than just modelling the domain. I feel it's important for a team that works in a domain to really get it. I think this looks like being able to explain the core of the domain and how it works in practice to a layperson.
I don't think this is necessary at all. However, to do a good job here, it's critical that the people building the software understand the principles of how the domain works and how people interact with it.
To take this literal example: I'm not an accountant or bookkeeper but I've spent 15 years of my career working with people in this domain. Even when I encounter a new part of the domain I'm not familiar with, I find it easy to put together the need from my existing knowledge and figure out what we need to do.
Take an example where I didn't invest in understanding a (financial) domain: my team inherited a report generation script that a founder was running for Finance. Initially, we just tried to expand it to handle more transaction items. Because we didn't understand how this report was being used, we skipped issues, caused issues when we changed things elsewhere, etc. Our Finance team was pissed because we were making their lives harder with our total lack of understanding. The answer? Spend time with the Finance team making sure every engineer understood what this report contained, what it was being used for, why it was important.
> In a software world dominated by technical requirements, how to determine and model functional requirements in an external domain can be what makes a programmer a great one.
I agree here, I just think that this understanding needs to go a little deeper than just modelling the domain. I feel it's important for a team that works in a domain to really get it. I think this looks like being able to explain the core of the domain and how it works in practice to a layperson.