alt Hacker NewsIt's interesting that domain experts all exhibit the same cognitive issue - their assumptions are just so ingrained that they cannot articulate it at all.
The fact that they "know" a missing stub would have a type is because they actually have some more information than they let on, and this information is only known by the expert. For example, they know if the submission was from party A, it must be type X.
But that fact might not ever be recorded in the computer system, in a way that the old business process would've had a record of.
And this is just one small example - imagine something more complex!
So realistically, the job of a programmer is to force an expert to articulate all of their assumptions. IMHO, the best way to do it is to be sitting with the expert, and observe exactly what they do.
Replies
I work in the energy industry at the moment, we spend a lot of time looking for a stakeholder / domain expert, and they all seem to point at each other; nobody has the complete picture of one domain / feature, or nobody has the confidence to own and decide upon all aspects of it. That is, that "side" of the organization spends a lot of their time in meetings and writing emails to try and decide on things.
> For example, they know if the submission was from party A, it must be type X.
Ha! As far as I remember it was almost exactly this when we interrogated them (but it's been a while).
> IMHO, the best way to do it is to be sitting with the expert, and observe exactly what they do.
Or you give them a prototype of the program, and see what they complain about?
you might say the domain expert expects the coputer to also already be a domain expert
My experience with "business domain experts" is that the majority of them are simply executing a process that someone else defined a long time ago. Their definition of "success" is usually that all steps within the process execute successfully without error and they can move on to the next transaction or activity. Very few of them are capable of taking a step back and considering what the process is actually trying to achieve and whether there might be a better way of accomplishing it. This leads to constant "paving of the cowpath" where archaic processes just get replicated in new technologies every so many years.