I believe that a lack of domain knowledge is the root cause of a lot of very bad software that gets developed and I think that it is up to computer programmers and their managers to deal with this. Acquiring domain knowledge is an essential component in the development of software that really works well for its users. A programmer that has to automate a warehouse but that has never picked an order and doesn’t have a clue about actual logistics is going to be writing far less effective software than someone that has done a few shifts on the floor. And that’s purely practical knowledge in a field that is reasonably well understood. There are many other examples where the effects of the differences between someone automating some solution with or without domain knowledge would be far harder to see.
Programming and systems analysis are like architecture in many ways. An architect has to have a reasonably good understanding of what a customer is going to do with a building if they’re going to do a good job of designing that building. An enclosure for a machine would have to match the guts of that machine just like a building encloses a company. Having the loading docks of a warehouse on the fourth floor is usually not what you want.
Software is much more intertwined with the institution commissioning it and the people using it than any building ever will be, with the exception of engineered structures such as the CERN ring. If all should fail a building, no matter how mismatched can always at least be used for storage. I’ve seen fire-stations converted to houses and industrial buildings converted to office space. But software that doesn’t match is unusable.
Imagine architects designing a fire station without consulting with fire-men and fire station chiefs and without understanding the basic operations of a fire-station and how the situation develops when a fire is called in. When utility matters, domain knowledge is very valuable.
Over the years I’ve worked on a large number of projects in a variety of industries. One of the things that I absolutely love about software is that it is everywhere, there isn’t an industry that doesn’t have software component in it nowadays. And for each and every one of those projects there was a large amount of domain knowledge to acquire. That’s hard work, and you probably can’t put it on the bill but it is an absolute requirement if you want to deliver a half decent product.
What that translates into is that when I worked for a company making CNC equipment that I learned how to use a mill and a lathe manually. Only when I understood how you work metal by hand did I reach a level where I could confidently write software to work metal by numerical control.
Working for a manufacturer of sails I soaked up piles of books on sail making and sailing and I actually spent some time on a boat. Half the library on that subject was digested for breakfast, lunch and dinner. Add another helping on fabrics and their properties and on stitching and cutting techniques! Knowledge like that helps a lot when you have to lay out your ‘panels’ on the cloth, and then afterwards when those panels have to be combined to form a sail. In that particular case I took great care to make sure that the panels had their major lines of stress run along the threads in the weave, even if that meant that we might get one or two fewer panels from a piece of fabric the resulting sail would be stronger and it would last longer. Quantity or quality is a business decision and if you’re not aware of this then you might accidentally make that decision for your employer without anybody being aware that a decision has been made. The software used the exact same terminology that the sailmakers used, and used it consistently.
When working for a company that did colour calibration software and pattern checking I read and learned about colour spaces and imaging hardware. All kinds of history there, from manual inspection to semi automatic inspection all the way to the present day. Industry is funny that way, you start out with a simple assignment (can you read values from this sensor) to sucking you in into a project that has a century of history behind it with lifetimes of domain knowledge that you need to absorb before you can even begin to properly automate the solution to some problem. It is also funny in that it all ends with knowledge about physics.
If there is a message in this blog post then it probably is that if you are currently working on a project that requires domain knowledge but you don’t have any of that knowledge yourself that you should probably take the shortcut of stopping your work and to first educate yourself about the field that you are operating in, and then to return to whatever problem you’ve been assigned to solve.
Programming without domain knowledge for a discipline that is steeped in it is like an architect designing a building without knowing its true purpose.
If you are working in some industry spend time on the shop floor, become a user of your software if there is any opportunity to do so. It will make you a far more effective programmer and it will reflect itself in the usability and the perceived quality of your software. The combined knowledge about the domain you are operating in and your IT knowledge is far more valuable than any of the two in isolation.
Domain knowledge is not optional, it is essential. The one common factor between the failed projects I come across is that they were automated by people that had little love for and little or no knowledge of the domain they were operating in. Companies and institutions should make time available to get their IT staff up to speed on the inner workings of the company and should allow their IT staff to be embedded on the floor for a taste of what the real world looks and feels like.
So stay clear of the trap of little or no domain knowledge and get your hands dirty, learn to see through your users eyes by acquiring the knowledge associated with the field you are working in, don’t treat IT as a world that only communicates with its users through tickets and requirement documents, step down from that ivory tower.