Recently on several LinkedIn groups there have been much discussion on the professionalism of the software industry. The analogy that seems to work is that of regular building construction. The term “construction worker” and “software development engineer” appears to be equivalent for the lack of meaningful information.
First item is the “development” in the phrase. Many SDE’s have never done any development (build new houses), instead, their work life is maintenance(fixing bugs) or renovations (adding new features).
A construction worker could mean:
- A journeyman brick layer
- A journeyman stone mason
- A brick layer trainee that still needs to be supervised for mixing brick mortar
- A licensed electrician
- A draftsman creating building plans
- An architect designing the building.
Titles in the software industry (and the associated job description generated by HR from the title) are equally unclear and contributes significantly to the high rate of software project failures (i.e. houses that collapse in the first wind storm, shifts in the first heavy rain, condemned by the county inspector, deemed not insurable by insurance companies [which means no conventional mortgages], rejected by the person that commissioned the house because it was not what they asked for, etc.). The analogies are strong because the human-ware problems are the same. The software industry uses Patterns – well, the concept of patterns came from the building industry – specifically the work of the architect Christopher Alexander at the University of California, Berkeley (I have most of his books in my library – they are an excellent read to understand what patterns should be and how to find them).
When you build a house, there are 3rd party independent inspection at almost every stage. Before building, the county reviews a host of documents like zoning (legal), geology (flood, landslide area), and utilities. If there is a building loan involved, the bank will inspect the plans for items like costs to connect utilities, drill wells, septic systems etc. Once construction starts, there are regular building inspections – these inspections are often mandated by the insurance industry which will refuse to insure the building if they are not independently inspected. Whenever the building is subsequently transferred, there may be requirement for a building inspection, and a new inspection by an insurance agent.
When you build a software system, these safety checks do not happen. Often there is no independent review (or a conflict of interest reviewer is used: for example – using an Accenture reviewer when the project will be staffed by Accenture consultants).
The solution is actually interesting – require the software project to be insured. Where do you get such insurance, well the tradition source for unusual insurance is Lloyd’s of London.
They will mandate due-diligence before giving a quote, they will likely give recommendations on how to reduce their premiums, and if the project fails – you are insured!
The result of such insurance is that the industry will become more mature and professional. There will be less risk for each software project – after all, professional independent risk managers will be involved to prevent foolishness often seen today.
- Startups can run without insurance, but established firms should have every project insured.