Introduction

Throughout the duration of my software development career, I have worked in the insurance, telecoms, education, social media, and travel industries. During the various interview discussions:

The insurance company wanted an insurance guy.
The telecoms company wanted a telecoms guy.
The education company wanted an education guy.
The social media company wanted a social media guy.
The travel company wanted an travel guy.

Sadly for all of these companies, they ended up with me instead, the software guy, and yet somehow we all got along just fine. So why is that?

Software knowledge > business knowledge (on software projects)

The reality is that very few business domains have unique problems to be solved by software. Most projects that I have worked on in my career have boiled down to:

1. We have a database with our core business data in it.
2. We want to wrap that database in some services.
3. We want to wrap those services in some clients (web, mobile etc.).

You might think that your business domain is uniquely hard, that it has complex concepts that are going to be difficult to map to software solutions, that your ideal hire needs to know your business domain inside-out before they could even attempt to tackle it, but for 95% of the projects I have worked on it has all mapped back to variations of database->services->clients, or even more simply "data in/data out".

Conclusion

Building software is widely accepted as a business domain all by itself, requiring years of training and practice. In many instances, software is not a business enabler but has become the business. Hire a software guy to build your software, and a strong business analyst or solution architect to worry about mapping the domain concepts. Industry experience in a given domain for a software guy is secondary.