Interdisciplinary Algorithm Construction with Non-developers

Question

Yeah, I know the title is a mouthful...

What I mean is to say is how do you communicate with a subject matter expert who needs a theory coded and tested?

For example, weather simulation is a collaboration between meteorologists, computer scientists, and software engineers. The computer scientists and software engineers generally speak the same language, but he meteorologist is in a completely different world.

How do you increase the level of communication and understanding between disciplines? And not necessarily just for weather, other sciences too.

Answer 1

The shortest possible answer is Continuous customer involvement.

All the pretty UML diagrams, crayola UI mockups, explanations-to-four-year-olds and other techniques will never give the full experience of using a working application. Keeping the consumer in the loop allows for a feedback cycle both to the client, and from the client to you. This symbiotic relationship has the greatest likelyhood of producing a product that will be useful to them.

If you go into a box and come out with a product that you think they need it will likely be a whole lot of what they don't want. By regularly demoing your product you limit the impact of any misunderstanding, so that you don't spend too much time going down the wrong path.

It can be compared to dead reckoning. If you blindfold yourself and try to navigate through an area you know, the error between where you are and where you think you are will accumulate with time. If, however, you take off the blindfold periodically you can update your mental location. There will still be an error factor, but you are eliminating the accumulating error factor.

Even if you think your communication/explanatory skills are top notch, you still have to account for error in the way they communicate.

Answer 2

With great care and patience. You cannot assume understanding so use a technique like prototyping or pictures to communicate.

When the customer makes a statement you need to implement what you think he says, or draw a picture of it and show him. It is easier for him to recognize your misunderstandings this way. I would avoid long written descriptions because its very difficult to know if you understand.

The customer should not need to know your language, so do not try to teach the meteorologist the CS lingo. You need to learn his language. Even the most trivial requirement should be tested with a prototype. If they say: "We need to see a map of the US", then you need to draw a map of the US and show them and say "Is this what you want to see"? He's then going to say "But I can't see the mississipi river on this map" then you say "but you didn't ask for rivers" Then go back and re draw the map. etc etc.

I have had situations with much simpler requirements that went horribly wrong because the customer assumed that it was simple and I assumed that I understood.

Answer 3

"The shortest possible answer is Continuous customer involvement."

I suggest you do this through some specific approaches.

1. A language in which you can develop quickly. Python's my choice, yours may be different. Java -- for example -- might not be high on your list because it takes a while to get stuff up a running. C++ may be too much effort for rapid development.

2. Build small things quickly. Start with something -- anything -- that can get the conversation started. Build, review, expand.

3. Formalize results with unit tests that allow you refactor early and often.

Once you have something solid, you can consider rewriting in Java or C++ or something to improve performance.

Answer 4

State Diagrams work wonders for that task. They allow you represent a computational process at a level suitable for the people you are communicating with. The states hold a brief comment on what processing goes on there. The arc between states show the conditions that cause a transition to a new state.

Having constructed the basic state diagram, you can move on to discuss the information that is being fed into the state machine. This is where the persons domain knowlege ought to come into play. Follow some data though the diagram to see the flow of how it gets processed. Generally at this point, they start to notice other situations that haven't been discussed.

It may be necessary to drag in another white board, expand one or more of the states into its own state diagram.

Then generally, when they are comfortable with the flow, it's time to inject error handling into the diagram.

This technique has worked pretty well for me.

Answer 5

I've always found that flowcharts are universally understandible, especially when representing algorithms. Flowcharts are generally easy to read and make, and are universally understood.

Answer 6

I've had good success with Weiger's stuff: http://www.processimpact.com/reqs_book/reqs_book.shtml

Start by doing a vision and scope document: http://www.processimpact.com/pubs.shtml#requirements

Answer 7

You should always ask yourself, "How would I explain this to that ol' granny at the market?". Once you have that covered, you can talk and explain your methods and procedures to pretty much anybody. If they have some additional knowledge, even better.

If you can't, than maybe you should ask yourself "Maybe the problem isn't on their side.". Even if it is on their side, there is no harm in trying to understand their point of view.

Personally, I'm not a programmer by trade, but had never any problems talking with ones, as long as we both stick to the aforementioned principles.