In an enterprise software team, is it recommended for developers to maintain a business knowledge wiki to understand domain concepts and processes?

No.

Although we can acknowledge that this type of documentation is popular. You can't look at the idea without recognising the problem of ever expanding wikis, confluences, sharepoints, read.mes etc which seems to hit any largish organisation and which renders the documentation worse than useless over time.

With this in mind I don't think I would ever recommend "starting a new wiki" regardless of the topic.

Doubly so for the topic in question. I think its going to be too long and detailed for a wiki. If you expect the employees to understand insurance, or quants, or car sales then you probably should make sure they attend courses, training and industry events rather than have one of them write a wiki.

The only real way to share knowledge in a small team is to just answer questions when they are asked.

If you work for IBM or Microsoft, then millions of customers are paying for access to high-quality standalone documentation on long-lived applications, and accordingly those vendors are paying for dedicated staff who are experts in producing such materials. They are also large enough to consume the same documentation internally with immediate usage, and reflect on feedback from readers.

Most developers are not such experts in anything like the same circumstances, and so most documentation done for its own sake ends up being write-only.

Well-written and well-organised source code, with occasional comment lines, is typically the best you can hope for in a small team.

If any documentation is produced, I would suggest a rough rule of thumb of one page per likely reader, or one page per man-year of development, and an iron rule that the documentation should not be just an English translation of the source code.

In my experience, wikis are fairly common, but their usefulness can be debated.

Regardless of how you do it, documenting processes is important to ensure knowledge is not lost if someone leaves. Having some kind of training documents to introduce domain concepts can also be useful, but often less critical since you still need some amount of in person training.

Using a wiki for such documentation has some advantages compared to some other kinds of document management systems.

• Navigation is easy.
• Searching is usually reasonably good.
• Changes are automatically tracked.
• It encourages contributions from everyone.

But there are also some disadvantages

• Editing can be difficult for non technical people.
• It may be more difficult to enforce formal processes to documentation changes.
• Having a distributed responsibility may result poor organization and outdated information.

In the end a wiki is just a tool, its usefulness will depend on what your needs are, how you are using it, and what other tools are available.

In my personal experience it has been reasonably useful for processes and documentation related to development and IT. Probably since technical people are comfortable with using such tools and spend some effort keeping it reasonably up to date. Business people, and especially sales, has been mostly uninterested. So if the main goal is business related information some other kind of system might be more appropriate.

Depends. All other things being equal, it would obviously be convenient to have such a resource. But it is a lot of work to create and keep updated - time which could also be spent fixing bugs and delivering features. So you have to weigh the effort against the benefit.

First ask yourself why the organization does not already have such a resource available for the whole organization, not just developers. Surely non-developers would also need to know the business processes, rules etc? If the answer is, it is too much work to make and keep updated and it is just easier to teach new hires in person as needed - then this is probably also the case for developers.

In some domains, like medicine or aviation, there are a very strong culture and processes around documentation. But other organizations might be much less rigid and processes might be altered on the fly as needed, which raise the question: Who is going to keep this documentation updated? The moment the documentation is just a little out of date, you will need to ask around anyway to get the true picture, and then developers will stop using the documentation.

Here’s something completely different that a company did that I worked for: We had competitors. As developers, we knew the strengths and weaknesses of our product. We only knew what our competitor’s marketing departments said about their products. And their marketing was better than our reality.

So someone invited some guys from our own marketing department and they sold us our own product. It was an eye opener and extremely motivating for everyone.