[moomin]

In my experience, often it’s hard to find that person with deep domain knowledge, and even when they do, it’s unstructured, they take things for granted they shouldn’t* and the have no appreciation of the demands of formalism.

Getting anything you can use to construct a work plan, never mind a detailed feature list, out of clients can be a dark art.

*To the point I have repeatedly experienced a point close to the end of the project where they go “What do you mean you don’t handle a case I have failed to mention for the entire duration of the project?”

[dcminter]

I recall a spec doc from a domain expert that said something like:

"The transaction consists of a credit stub and a debit stub. If the debit stub is missing and is of type X then we do A and if it is of type Y then we do B."

How to know what flavour the missing item was? Absolutely no mention of that...

[chii]

It'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.

[DebtDeflation]

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.

[chii]

That is a fair point. The programmer will have to learn the process, but also understand the process' goals and intentions.

If they do, then they by definition become a domain expert. It's just that this takes a while, and projects usually don't give enough time for such to take place unfortunately.

[Cthulhu_]

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.

[dcminter]

> 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).

[eru]

> 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?

[Seylox]

Oh, you're onto something. May I slap a sticker on it and call it "agile"?

[normie3000]

How about "extreme programming"?

[eru]

I have much more sympathies for 'extreme programming' than for 'agile'. Mostly because I see many more clueless people use 'agile', while 'extreme programming' seems to be a term that time forgot and eg http://www.extremeprogramming.org/ is still in a state of relative innocence. The website was apparently last updated in 2009.

[discretion22]

My experience is that invariably results in "development by veto". Each prototype they say that's not what I want, give me something else (that I'll fail to describe just like the last time) and I'll tell you that is wrong too after you've worked on it for a few weeks.

Occasionally, you'll randomly get something they accept - but only for a few weeks until they come across some missing capability for some other thing they never told you about.

[eru]

> My experience is that invariably results in "development by veto".

Yes, I wasn't entirely serious.

Though you can get pretty far by doing some roleplay, where you pretend to be the computer/system (perhaps put up paper screen to make it easier to roleplay, and pass messages written on paper) and have the expert interact.

[randomdata]

You still have to actually listen to the complaints. "That's not what I want" does not mean try again, it means they have no interest in what you are trying to offer in even the most basic sense. The lesson from that type of complaint is that you are barking up the wrong tree. Time to move on to something else.

When you are solving a real problem, you will still receive complaints, but they will be much more constructive.

[zknow]

you might say the domain expert expects the coputer to also already be a domain expert