Hi,
What, in your opinion (although I would highly appreciate articles / books on related issues), should be the the level of the programmers knowledge of the domain?
(This related question didn't quite answer my question / had a reference to something I can use)
As a consultant I am constantly (every 6 to 12 months) changing domains. Though I can never proclaim to be a true expert by the time I finish a project, the more domain knowledge I acquire, the more value I can add the project.
That depends on how related to the domain the specific job they're doing is. In team context, I can imagine that the lead programmer and some others benefit from a bit of domain knowledge while others in the team don't need it.
- Banking/financial applications
- Networking/wireless/telecom
- Mobile Applications
- Web/storage/enterprise/Numerous others..
If by "domain" you mean your area of work, yes you should strive to understand everything related to your area of work. How far into other areas that extends is another question.
If programmers were domain experts, they would not be programmers. :-)
For example, I do a lot of software development for archaeologists. If I knew as much about archaeology as the users I work for, I would be digging and surveying in the field rather than programming. Which makes no sense.
Having said this, I think that programmers need to ne knowledgeable about the domain, and much as possible, but without losing track of priorities.
If you need domain expertise, bring a domain expert into the team.
programmer is like people who can interface "other people" with computer by creating software, and better understanding of the domain where you're working for would help the communication between the problem and the "other people" thus would make you a better programmer.
but the problem domain is often very wide and deep, you can expect everyone to be expert at programming and expert at another field, for example you can expect great scientist or physicians to be expert at programming to solve his problem when creating space-ship because programming is not his main concern, so with programmer, but programmer or scientist who can talk to each other is the best fit
Yes and no.
As Kyle pointed out, programmers are often changing domains on every project and this pretty much precludes you becoming an "expert" in any given domain. On the other hand, you need to understand the problem well enough to a) craft a solution, and b) test that it actually solves the problem at hand.
One reason for not claiming domain knowledge is so that your customers are forced to take ownership of this part of the project. The best way I have fouond of forcing them is to require a clear overall description of the project (no more than a couple pages long) plus a ton of User Stories ... written by the users. You can lead them through the process of how to write US's, but they will not truly own the end solution unless they were intimately involved in creating it.
Having US's and using them both for design and testing puts project ownership where it ultimately belongs -- in the hands of the users of the system.
If you don't understand the problem domain, you shouldn't be coding a solution.
You don't have to be an expert, but you cannot be ignorant of the key ideas. As a FORTRAN expert, you won't make any progress coding an FFT unless you have some background in signal processing, and understand why an FFT is necessary, and know a variety of implementations.
Even if you change projects and with them domains frequently, domain specific know how and experience in one sector (or branch of trade) will be always a plus.
I look at this as "WHAT" versus "WHY". As in What is the business requirement versus Why is the requirement such as it is. A junior programmer only needs to understand the WHATs of a project. An analyst needs to understand both. In my opinion and my professional status, to stop being a developer and to become a software engineer, you need to add analyst to your skill set.