Licensed professional engineers can be trusted to build bridges that go up according to plan and stay up. Some have proposed that same concept for software professionals – maybe licensing could be a means of indicating that they can be trusted to build software that goes up according to plan and stays up.
But I believe that licensing of software professionals would be a serious mistake. The right kind of certification could help, but now is not the time for licensing.
To begin, let me clarify the difference between licensing and certification. A license is granted by the state and allows its holders an exclusive right to practice. Doctors need licenses. Lawyers need licenses. Some engineers need licenses. The theory is that licensed professionals can be trusted to be ethical and competent – failure can result in the revocation of their license.
Certification is a voluntary process. It’s driven by market forces which put value on the claims that can be made by those who are certified – the market values what certification attests.
Vendors certify individuals as knowledgable in their products. There are dozens of such certification programs in computing. Although some vendor-independent certification programs in this area do exist, they have not yet had great market success.
There are important practical differences between building a physical structure and building a software system. With a physical structure, design is a small fraction of total cost, but with software, design is most of the cost.
An iterative cycle of ‘design-build-test, design-build-test’ makes no sense for most physical structures, but can be very sensible for software systems. A physical structure is local – providing a place where a license can be required, but a software system can be built anywhere, and be running anywhere else – it’s difficult to identify where a license should be required.
There are important differences in theory. The physical sciences provide the bedrock upon which to base sound engineering practices. There is considerable agreement about the body of scientific knowledge that must be mastered in order to do engineering. Although there may be some scientific principles which can be used in building software systems, there is much less agreement about the body of scientific knowledge that must be used as the foundation for software practice.
There are important historical differences. Many areas within engineering have had centuries to develop standards of practice. Even the newest engineering areas have the comfort of a well understood physical reality against which to test proposed standards of practice.
Software professionals are developing standards of practice. We have recently begun to make real progress, but our emerging standards are not grounded in the same kind of well established scientific understanding. Our standards of practice cannot be as absolute as those in engineering.
Given where we are in software, licensing would be a mistake. We are in no position to deliver the public benefits required to justify the social cost of licensing software professionals.
Certification is a different matter. Voluntary certification, built on emerging standards of practice, could be a positive force to improve our ability to deliver software that goes up according to plan, and stays up. It’s something we need to seriously consider. I urge you to join in the effort to make it happen.
Fabian is a senior management and systems consultant in Toronto. He can be reached at robert@fabian.ca.