I have come across analogies in the past where people have attempted to draw similarities between construction and software development. After all, both have “architects,” use “tools,” and “design” before “building.” I’ve compiled a short list of reasons why this just isn’t so…
1. Unlike builders, developers do not have domain expertise in what they are building.
When most of us approach someone to build a house for you, we rely on and trust that the contractor posses more knowledge and skill than we do. After, it’s his business to know these things – and if he doesn’t, we expect that he knows who to contract with for specialized knowledge and abilities, like plumbing and electrical work.
When it comes to insurance software there is a divide: insurance professionals who understand the business and software developers who understand how to design and write software. To produce business software, there must be a meeting of the minds – and it is imperative that the developers understand what needs to be built in order to fully meet the needs of the business, otherwise you will likely “get what you asked for, but not what you wanted.”
2. Business software is difficult to fully blueprint and visualize.
Houses can be blueprinted – and these days 3D software can be used – so that it is easy for anyone to visualize what they are getting. The fact that there are a great many houses in the world helps the visualization process as well, unless you happen to be so wealthy that you are designing something that is completely out of the norm. The point being there are no real surprises (issues with your contractor aside) from what was designed to what was built. You wanted four bedrooms, you got four bedrooms.
Insurance software, on the other hand, is comprised of visual elements (the user interface) and processing logic that goes on behind the scenes. This business logic defines the behavior of an insurance system, but this is not easily blueprinted or visualized. And unlike prior experience with houses, new software is just that – something that the users do not have prior experience with, so the ability to accurately and precisely specify what “it” is can be a very difficult task.
A tremendous aid in the software world is having insurance professionals work with development teams to create validations (test plans) that describe how they expect to use the software, and to articulate the expected results of any behind-the-scenes processing logic as the system is being used. It helps to shape and define what is truly expected.
3. The technical foundation and tools in the software world are constantly and radically changing in short periods of time.
Tools and technology are changing in the building contractor’s world as well, just not to the extent that the computer world is changing. Consider this: the simultaneous changes to technical platforms – DOS and the various versions of Windows over the years – database engines, the migration to Web-based computing, programming languages and approaches like object-oriented programming, service-oriented architecture, etc. have occurred so rapidly and changed so radically that if you didn’t keep pace, your knowledge and abilities as a programmer would make you obsolete in less than a decade’s time. As a contractor, well, a hammer is still a hammer, and a nail is still a nail…
4. The same application is not being written over and over again.
In many ways, building a house is like building the same application over and over again, making modest customizations relative to the core design. And yes, there are variations possible: one-story versus two-story, colonial versus cape versus ranch, etc. The basic approach, techniques and tools remain common. In the software world, if essentially the same applications were being written without new demands being made, you would observe significant productivity gains (and lower costs) for writing the same application using new tools.
However, when new software is being written, it is because new demands are being made, either in terms of the business functionality being provided or the use of the latest architecture and platforms to ensure application longevity, or a combination of both. Often, this necessitates that the latest tools be used and that research be undertaken to determine how new tools, techniques, and technologies can best meet the business demand and allow the application to be maintained over time.
5. Even small mistakes in software can be catastrophic.
Small mistakes in houses do not cause a house to cave in around its owner. Little issues can be corrected, doors can be adjusted to close properly, shims can be used to level surfaces. The house can still be used, and used without adverse affects. In the software world, one small error can allow a hacker to access a web site or allow a program to access memory that it wasn’t supposed to and the application will crash – and if the user was in the middle of a transaction, business information (data) may be lost or corrupted.