How do you go about learning domain knowledge for a project?

Question

I have only recently gradulated (6 months ago) and am working for a company that makes software for the mining industry. I have found it is the developers that know the most about mining that write the software the users like best (even if their code is not so great). Obviously domain knowledge is important, maybe the most important thing to writing great software.

My question is how do you go about learning domain knowedge about the field you are working in? I have tried reading textbooks, but most of them are geared towards geologists, and I don't have the background information needed to understand what they are talking about.

Talking to the users is good too, but they don't always have lots of free time just to explain background information.

Answer 1

Are there any customer reps or sales people in your organization? People whose job it is to explain or support the software often knows a lot. I teamed up with a customer service rep in an advertising application, and he appreciate having an engineer to ask questions (why things in the program worked like this, what should we do in this case) and I could pick his brain on what were the features he used most often, what the people talking to him said about the product, and so on.

Maybe try to make friends with the folks closer to the users.

Answer 2

Lots of hard work and effort!

Take part in as many meetings as you can. Try and break down the project you're working on to the point where you can understand exactly why you're writing the code you're writing. It takes time but as you say, it's worth it.

Talk to the users, talk to the developers that already know the knowledge, talk to everyone! Don't worry about not getting it all or if it's taking a long time! You're good at your job, they're good at theirs. You're just trying to get an edge by understanding a bit of theirs!

Answer 3

You say that your users don't have a lot of free time, I'm presuming that this is during working hours. One way to get over this is to schedule your time with them, set it up as a meeting so it appears in their calendar, then they won't view it as free time. Also explain to them your observations and that in spending time with you up front it will in fact save time and deliver better results down the line...

Another option which I have used in the past is to bring a small bit of work talk to a social environment. During a night out for a few beers asking them how they think IT is meeting their requirements and what could be done better will get you surprisingly forth right views, just don't take some of it to heart.

"What could we be doing better for you"

Is a question that they will be only too pleased to answer and the following discussions will expand your knowledge... just don't drink too much so you remember the good stuff.

Answer 4

One thing that helped me was to just find a good mentor in the company. Look for someone who is really knowledgeable in the domain, and who is willing to spend some time with you every week, consistently. If the documentation is bad or non-existent, you'll probably have the best luck just talking to the people who know the domain.

Other than that, just read as much documentation as you can, and try to relate what you're reading to the code.

Answer 5

Congratulations, you've just learned a very important lesson. There are two difficult problems in writing software: finding out what the software should do, and implementing it. Often, the first is by far the most difficult.

That said, there's no easy way to get this knowledge. Use all the contacts you can, aks questions, try to attend courses for users of the software, or do (targeted) reading and websurfing. It will take time, but you'll get there eventually. And often it already helps to only have a sketchy understanding. You can (and should) fill in the details later.

Answer 6

Go and watch the real end users operate the software for a few hours or longer. Don't necessarily ask them for a instructions or such but rather just sit and watch during the course of normal work; they'll end up telling you all their problems anyway.

I've always found that the best way to get to grasps with a new situation.

Obviously it's no good if the project is for brand new software but that's pretty rare and most of the time the job is enhancements or maintenance on existing code.

Answer 7

A lot of good comments on talking to end users/domain specialists - if those are available to you - the pHD's love to talk/teach so they are your best bets in technical areas.

• Ask to see if there are any introductory/college level texts on your domain.

• Find the trade magazines the company gets. they might not cover your specialty but you will see the broader industry and learn broader knowledge.

• Look to see if there is any training material that has a sample problem for the software and if the company offers training courses or there are training courses for the specialty you are in, such as smelting, resource development, geophysics/geochemical etc.

• Also there are lots of good things in wikipedia - just type in keywords you have seen in the software or have heard about when hanging aorund domain specialists to get terms/words you arent familiar with.

Answer 8

You can't beat going out and watching your users, in your case visit them on a mine site if that's possible. I sympathise with your reading issue, imagine trying to find out what it's like to be a dev, by reading a C# manual - can't be done. You need to see you're users on home turf.