[dTal]

Obviously anecdote != data, and you don't say what the software does. But your story would seem to imply that domain knowledge is more important that software development knowledge. There's a certain logic to it - someone who deeply intuits what the software is trying to model will naturally gravitate towards the correct abstractions, even if they're ugly and ad-hoc; while a professional software developer with no domain experience with happily build a shiny tower of abstraction that doesn't fit the problem domain, and chaos will ensue.

There's a reason we emphasize nailing down requirements before committing code. But what if it goes a level deeper than that? Perhaps what we actually need to do is understand the mindset that is generating those requirements. Perhaps, for some types of software, that's equivalent to being a domain expert.

[TeMPOraL]

> But your story would seem to imply that domain knowledge is more important that software development knowledge.

I think the story suggests alternative explanation: that the product is a side project for the people that make it, probably even considered as a marketing expense. So they don't have the usual software-house incentive to fleece the government while delivering worst possible product. Wouldn't be surprised to discover that these dentists don't consider it a high-pressure project, so they actually take time to do it right and be proud of their work.