Must developers understand the business domain or should the specification be sufficient?

Question

I work for a company for which the domain is really difficult to understand because it is high technology in electronics, but this is applicable to any software development in a complex domain.

The application that I work on displays a lot of information, charts, and metrics which are difficult to understand without experience in the domain. The developer uses a specification to describe what the software must do, such as specifying that a particular chart must display this kind of metrics and this metric is the following arithmetic formula.

This way, the developer doesn't really understand the business and what/why he is doing this task. This can be OK if specification is really detailed but when it isn't or when the author has forgotten a use case, this is quite hard for the developer to find a solution.

At the other hand, training every developer to all the business aspects can be very long and difficult.

Should we give more importance to detailed specification (but as we know, perfect specification does not exist) or should we train all the developers to understand the business domain?

EDIT: keep in mind in your answer that the company could used external developers and that a formation to all the domain can be about 2 weeks

Answer 1

The specification is virtually never sufficient. Developers who do not have domain knowledge cannot point out when the specification is in error (a frequent occurence most places) and make poor design choices.

Answer 2

In my experience, having worked in 3 very different industries now, you can start out not knowing much about the domain, but you'll need to learn it eventually and someone will have to understand it to a detailed degree.

The essential problem is down to the client-developer impedance: they want something but will only know it when they see it and you want to solve their problem but can't always get a clear idea of what that problem is. The more domain knowledge of their (the client's) industry you (the developer) can bring, the easier you can translate vague "wants" into concrete "problems" and solve them.

As an anecdotal example, my previous job was in the chemical industry involving plant management software. I started with effectively zero knowledge of the domain, but was able to implement the code I needed to solve sub-problems presented to me by the senior developer and the clients. Over time, I made the effort to learn the industry, so that I could communicate more readily on the client's level. As I understood their industry, I began to understand what the actual problems were. When they say things like "we need to track all the data values on this module" I can translate that into what they really mean, which is "we need to keep a historical record of each value this sensor generates, stored for X days of retention, but always evaluated based on the most recent reading from that sensor." A lot of domain problems have hidden rules (like retention periods on data) that the clients have internalized, but you need made explicit.

So yes, someone needs domain knowledge, and preferably a developer because domain problems are not code problems and translating between the two is not trivial. Eventually, any developers worth keeping on your team should pick up the domain, so they can make more informed choices about the nuances of their code.

Answer 3

SOMEONE on the project needs to have fairly complete domain knowledge. That person may or may not be the developer.

In Agile projects, the client project owner is that person, and they're working collaboratively and closely with the team. In non-Agile projects, somebody on the team needs to acquire that knowledge, but they usually don't, which is one reason why non-Agile projects are so failure-prone.

Answer 4

If you put a person who knows only English and a person who knows only Japanese in a room, they wouldn't be able to translate from Japanese to English, in spite of being experts of their respective languages. For the same reason, even expert programmers with no domain knowledge are powerless at figuring out what they needs to build, even when they have a 24x7 access to the best domain expert who is not also an expert at software development.

A spec is an attempt at translating "Japanese" of the domain requirements to the "English" of programming requirements. When you get translation quality comparable to that of Google translate, it is your lucky day; most of the time, the quality is just not there, so you have no way around acquiring at least some domain knowledge. With some persistence, it makes you a decent "translator" by the end of the project, so your value to your company grows significantly. Most of the time, you also have a lot of fun in the process, so it is a win-win situation.

Answer 5

There are a lot of excellent answers. I add my own because after reading them and searching I found that nobody mentions a key issue: bugs.

If the team is not provided with enough people with enough authority and domain expertise, sooner or later bugs will inevitably creep in. Given a knowledge of the domain, there are impossible, or non-sensical values/results/relationship. One could hope that a specification explicitly points them out but in reality the best you can reach is to avoid the most obvious ones (alert me if interest rates become negative, or things like that - this could be or could be not an error but is strange enough to be noteworthy).

This is strongly related to understanding the reasons for choices, and in the best cases it also leads to better software (because if one actually knows the reason behind a request, is able to think about it, rather than having to accept it as a given).

Remember that Einstein said "But thought and ideas, not formulae, are the beginning of every physical theory. ", that is that one thinks not in terms of abstract formulae but of ideas...

Answer 6

Without some aspect of business knowledge you end up with developers who don't ask questions and mindlessly code what the specs say. I believe it takes "Thinkers" to make good software not just people who can bang on a keyboard. Understanding not only "What" you are doing but "Why" and how it fits into the bigger picture helps provided greater satisfaction for the development team.

Answer 7

I think you should try to get the domain knowledge. Specs are check list saying what the end product should do and is required for the validation of your product. As developer you should always try to understand what is the real problem you are trying to solve. Getting the domain knowledge will help you understand that.

It will help you design and code easily as you will understand what are changing parts (say rule set) and put them separately. You do not need to be a master at it but would be able to speak to a end user in their language.

You can drive a car with basic knowledge of it; but in case you want to enjoy the ride you need to learn more on how to use it exactly. As with other trades, it is not mandatory to understand the domain, but it is fun when you do it.

Answer 8

I think a developer who knows the business is worth their weight in gold.

In a "traditional" scenario where the business has some requirements and some business analysts translate those into technical requirements then the developer works off of those you inevitably have two things which can happen:

1. You have multiple points of failure. The business analyst may not have gotten all the business requirements translated perfectly and/or the developer may not translate those into a technical specification perfectly. A variant on the "secret around the room" scenario. Just the exigencies of communication.

2. One or all of the business owner, business analyst or developer are new enough to the organization to miss key items that they wouldn't think about normally. The seasoned developer who knows the business well can assist in educating the people in those other roles to make the product more complete.

Answer 9

There are almost always trade-offs to be made between the value of each feature in the spec, how closely the spec must be implemented to valuable, and the cost of meeting any combination of spec features. Often good trade-offs can only be made when the knowledge to do all of the above exists in one person, or a closely working team, including the actual software architect and/or coder.

Without such extremely localized knowledge and possibly even gut feelings, the result can easily end up as a very costly nearly useless product that very closely meets the written spec.

The cost of creating a spec that does not have the above problems can often be greater than training the architect and/or coders to have enough domain knowledge to work with a less inscrutably detailed spec (assuming the legalities and business contracts allow this).

Answer 10

You don't have to, but why wouldn't you want to?

I would be concerned about any programmer who was reluctant and especially unable to learn the domain to some degree. It's important to get out of the "ivory code tower" once in awhile.

Writing code without having any idea how it is used and for what purpose just sounds like a terrible job. Who wants to just break bricks when you could be building cathedrals?

Answer 11

Yes developers need to know the business to a degree. They don't have to know every minute detail, but they should have a basic understanding of what report X is used for and how its used in the business process. The more your developers understand about the business the better the solution they can deliver.

Answer 12

Based on my experience*, a single individual with good knowledge of the problem domain and good knowledge of software development is more likely to find the optimal solution to a problem than two individuals, one with excellent knowledge of the problem domain and one with excellent knowledge of software development, working together.

I think it comes down to the simple fact that the communication that happens in the brain of a single individual is many times faster and better than the communication between individuals.

*The main experience I am drawing on to answer this question is 10+ years spent on developing an accounting software package (from inception to 'maintenance mode'). Although my knowledge of software development was pretty good, as compared to my colleagues, I often felt handicapped by a lack of understanding of the problem domain.

Answer 13

I'd like to answer as someone coming from the business side, who works with developers who show little interest in learning the basics of the trade, sometimes even seem to be proud of not having to know about those basics: The problem is that the developers will not be able to see mistakes in the result at first glance (unplausible results, wrong signs and so on), which requires either detailed test cases (which we didn't develop until recently), or constant supervision of the results. Insofar, as much as I am willing to learn the basics of software development to ease the communication, I'd like to urge developers to do the same.

Answer 14

The more involved that a developer becomes and the more senior in the business the more important it becomes to have at least mid-level domain knowledge or the more nuanced areas of that industry which may be critical won't be understood by the developer team.

However a specification should be suffcient for lower level tasks. In short, it's best to train your workforce to a lower level. They may be the best polyglot programmer in the world, but if they can not understand the issue fairly deeply they are always doomed to failure or death march programming.

Answer 15

There should always be some specification - you can't expect all developers to become domain experts. At the same time, if the developers blindly follow a spec without really understanding what it's for, the result may not really be what the clients want. It often happens that when a developer has even a somewhat decent (but not expert) level of understanding, they can catch errors and omissions in the specs. They can also contribute and give feedback to the process which can make the final product much better.

It might be worth hiring some domain experts whose job it is to liason between the clients and developers to help give the developers a better understanding and also to help write the spec.

Answer 16

I think this hard to give an answer either way.

It's hard to see how, say, a freelance developer can understand the business (or science) behind every single application they develop. In this situation, I think it is more important that the developer knows to ask the right questions about the spec or business model than to really understand the business itself.

An enterprise developer on the otherhand, assuming they have been in the same business for a while, really ought to have learned how the business works after a few months (or years perhaps). In large team you might also have an architect who understands the business more clearly than the developers.

In SMEs with lone developers it is important that the developer has frequent discussions with the owners/managers to avoid going off and implementing the wrong thing.

So there are lots of possible ways of thinking about this, but the key is the same in all cases: communication.

Answer 17

Software development is the only profession I know of that requires you to not only be proficient in your own profession but have a basic understanding of the profession that you are working in. It is important to have enough understanding of the domain to communicate with clients and other developers in the language of the client. As a developer you cannot always rely on others to train you. Sometimes you have to ramp up on your own with personal research, often times outside of typical work hours.

Answer 18

I really understand what you mean here because we, as company in a tourism industry, faced the same problem. When I was a junior developer, I was also studying tourism at a college. So, you can guess that I am not coming from a computer science background but my tourism knowledge is high.

We were building products in relation with other software companies back then, but domain specific knowledge was lacking a lot. As you described, it is really hard to get it right if you are building a product in tourism industry as there are many cross-cutting concerns, etc.

So, this movement gave a lot of bad results in the long term. Then, we took a huge step forward, and I started to focus only on development rather than the business part of the project. As I have the industrial knowledge and the programming knowledge, the project grows more efficient than ever. Not to mention, we can then make decisions faster since I have the experience on both sides of the coin.

As a concrete answer to your question, it is certainly yes in my personal opinion. If the project your team is working on is a long term project, then take the hard road and train your staff on domain specific fundamentals and details.

Answer 19

If a developer stays in a company/industry over a long period of time, they will slowly but surely learn "the business".

Some companies acknowledge and provide training in "the business". Financial companies are a good example of this.

The more you learn the business, the easier it will become to talk to your users. They will feel more confidence in you. You will more readily understand the quirks of where a system might go wrong if it doesn't quite do as expected for the user.

To answer your question, the specification is NEVER sufficient in my experience. The common problem is they often do not contain enough information, and get out of date quickly.

Experience of the business domain can be mandatory for some companies. They look for developers with experience in the domain when hiring. Some companies even put this higher than the actual tech skills. (No financial experience, no interview is very common, certainly here in the UK).

Answer 20

From personal experience, the specification is enough as long as you've got someone on the team working with you that does have the domain knowledge.

I work in a very specialized industry: we make software for broadcast media. I barely know a thing about broadcasting, but I know code and I know data, and I've got good people on the project management team that understand broadcasting. That formula's been good enough for the past few years for me to come up with good functionality that the clients like.