How concerned should a developer be with the problem domain?

Question

For example, let's say I'm working in the field of physics. How concerned should I be about the latest and greatest things in the field of physics in addition to the latest and greatest things in computer science and software engineering? Is it OK to just have a passing familiarity with the domain in which you are working? Does it depend on the domain itself how much knowledge you need to be an effective developer in it?

Answer 1

I think that every software engineer should have at least a passing familiarity with the field in which they are working, whether it's physics or banking or whatever. An engineer, especially when dealing with requirements or quality assurance, must be able to speak in the language of the customer and translate between that and the technical terms used by the development team.

Answer 2

(you could edit your question instead of answering it with more info...)

Answer 3

I've worked as consultant doing programming for 10+ years and I'd say yes. Creating a good solution behooves you to learn as much about the problem domain as time & money allows.

Answer 4

The more knowledge, the better.

In fact, in an idea world, it would be the other way around - it would be domain experts who also knew how to program doing the work.

Ultimately, computers and the programs that run on them are just tools. As easy as it is for developers like us to loose sight of, technology is not an end in itself, it is something used to accomplish complicated tasks.

But each of those tasks is not, in itself, a problem of Computer Science. It is a problem of a particular domain, and the more thorough understanding one has of the domain, the more likely one is to develop a solution that is practically useful to those in the domain and leverages all relevant facts.

Answer 5

Understanding the problem domain is critical. You do not need expertise in the field, but the ability to comprehend the problems, effectively communicate with your users and especially to developing a growing sense of what maybe be needed next will make any project more successful.

I have worked in the medical, banking, scientific, and now, legal files as a software developer. Each time, I make a full effort to immerse myself into my clients business. Each time I have done this I am able to develop a strong relationship with my clients and make the project more successful. Users truly appreciate when you speak their language, because it shows you are truly involved and concerned with their success.

For example, when I have worked on scientific applications I make sure to learn the terms and the very basics of the techniques and processes. Once I get a more detailed understanding, I see where the project needs to go even though my clinet may not tell me. While they talk about imaging, running gels, and RNA sequences I learn that they are using these to accomplish a much larger goal. Without a solid understanding of the problem domain, I would be reduced to a technician, i.e. code monkey, instead of a problem solver. You must wait on directions from you client when you limit yourself to being a technician, instead of producing ideas and solutions that add value. In my opinion the trap of only providing the technical expertise is one of the biggest failings of software development. If you own the problem, you own the solution.

Answer 6

My thought is that you should learn as much as possible about the problem domain as necessary for you to solve the problem initially, as well as to be able to trouble-shoot the solution effectively if problems arise.

Since that sounds obvious let me elaborate a little:

• If you are able to leverage the work or assistance of an "expert" to help you solve a problem, that's perfectly fine, as long as you are able to use this "expert" to assist in testing/trouble-shooting your software. Alternatively, as long as you work to fully understand the solution/assistance given to you by the "expert", that's fine.

• If you are unable to use an "expert" to help you solve the problem, you have to do the work yourself to learn enough about the domain to solve the problem yourself.

The worst thing that can happen is that instead of doing the work to understand the problem domain yourself you plug-in some code/formulas that you don't understand completely. This makes your solution a total bear to trouble-shoot if problems arise... and they will.

Answer 7

I like to think of myself as an inventor rather than a typist. People need to be told what they want.

If your clients or coworkers are sure of exactly what is needed and can explain that precisely to you, then that's (by definition) good enough. Your lack of specific knowledge doesn't matter then. However, in my experience, that's never the case.

Answer 8

It depends. Are you responsible for setting scope or identifying requirements? If so, you really need to know these things.

Do you have other access to 'knowledge experts'? If so, you can pass designs by them to ensure you are on track.

There is no substitute for having domain knowledge. However it doesn't have to be fatal to the project if there are others that can provide that input.