I work in the software engineering industry, but my undergraduate degree is in civil engineering. During my undergraduate days, I spent a lot of time writing software programs to solve structural engineering problems, and I ended up pursuing software as a career rather than civil engineering. As a consequence of my degree and early jobs as a civil engineer, I often find myself comparing the software industry to the engineering and construction industries. For example, while some schedule slippage is common in the construction industry, it is nothing like the software industry, where schedule slippage is (unfortunately) almost expected and universally accepted as a reality of the software process.
In the July-August 2006 issue of American Scientist, Henry Petroski (a Civil Engineering professor at
It is a great profession. There is the fascination of watching a figment of the imagination emerge through the aid of science to a plan on paper. Then it moves to realization in stone or metal or energy. Then it brings jobs and homes to men. Then it elevates the standards of living and adds to the comforts of life. That is the engineer’s high privilege.
I feel this way about software engineering as well. The software that we are writing can have just as significant an impact on the lives and wellbeing of our fellow man. Just as a concrete and steel retaining wall protects the lives of motorists by holding back soil and rock, so can screening software prevent the loss of life by preventing terrorists from entering the country. When I think about the projects that I have been involved with at Platinum Solutions over the years – writing software to improve the safety of prescription drugs, break codes used by terrorists, assist in the investigation of international kidnappings, improve the safety of naval and marine forces, render safe improvised explosives – I feel the same “high privilege” that Hoover mentions.
There are also some frustrations in the software industry that would have seemed foreign and strange to
I would also maintain that we as an industry have to figure out a way to manage software projects more like construction projects. As I mentioned earlier, the lack of planning and routine schedule slippage in software is just outrageous. In the construction industry, this just does not happen as often or to nearly the same degree because I feel that construction planning is much more thorough, and construction project management is much more disciplined. On a construction project, there are often huge penalties if the project is not completed on time – the contractor often has to pay tens of thousands of dollars for every day of late delivery. In the software industry, well, the contractor typically just gets paid more under a time and materials contract, or in some cases has to lose a portion of the incentive award fee. Consider a large scale construction project and the level of precision, planning, and rigor required to manage the delivery of materials, the activities of dozens of subcontractors, the various activities required (mechanical, structural, electrical, masonry), and all of the permit and inspection steps that are required before the structure can be used. Contrast that to a typical software project, where the vast majority of the activities involve a team of folks sitting at terminals writing lines of software code. While many of the tasks are similar (requirements definition, subcontract management, scheduling of critical path tasks, system accreditation, etc.), I still have to feel that we have it easier in the software industry, and yet our track record as an industry is so much worse.
In summary, I do believe software engineering is a great profession, and shares many similarities with the other engineering disciplines. It has its own rewards and challenges as well. I am optimistic that as the industry matures, we will be able to realize the improvements in process and efficiency that the more established disciplines now enjoy.
Comments
I came from Software Engineering background, but I have never relate S/E to Civil Engineering. Haha, you have make a good point.
One of the main differences between Civil Engineering and Software Engineering is that there are state licensure boards for engineers (of all kinds), and it is actually illegal to practice engineering in most (if not all) states without a license, but any schlub can hang up a shingle and call himself a programmer.
Programmer certifications such as SCJD, SCWCD, MCPD, etc. are excellent and important achievements, and I do not want to diminish their value, but there are at least four ways in which they do not measure up to a state licensure program. One, they are specific to one vendor's technology. Two, they are predominantly used as recruiting qualifications at hiring time, and are not looked at beyond that. Three, they are not compulsory. Four, you do not risk losing your certification if you bungle a project.
It seems rather odd to me that you have to have a license to cut someone's hair professionally, but you do not need a license to program a payroll system with all its confidentiality restrictions, or to program an accounting system that handles millions of dollars, or even to program an X-ray machine that can kill people (ever read about the Therac-25? We at Platinum Solutions of all people understand about software that has lives on the line.)
One reason that our bridges, roads, and buildings don't crumble under our feet because the people who designed them and built them are held accountable to a standard, and they absolutely have to have that accountability and reputation to find work. Until there is some sort of mandatory minimum standard of competency, safety, and ethics in programming, the world can expect systems to be delivered late, over budget, and below acceptable quality.
That is a great point Matt. I had to pass the Engineer in Training (EIT) test in Virginia, which was a brutal test. I never did get my Professional Engineer (PE) certification - that required a number of years of work experience and another test.
However, even though those tests will weed out people who are clearly unqualified, they certainly do not mean that the holder of the certificate will not design a faulty bridge. There is probably another factor coming into play: it is so much more difficult to spot a software defect than it is to spot a defect in a physical structure. You can have a software program silently failing on a daily basis, and it might never be discovered. I have been shocked to discover bugs in software that I have written that only became apparent years after the software was deployed, and yet the failure was happening consistently and was never noticed by users.
When a bridge fails, it is instantly noticed. Petroski mentions this fact in the article that I referenced in the parent post. He mentions that this is what keeps engineers awake at night with worry, going over the details "just one more time" to make sure nothing was missed. I don't know of many software engineers that lay awake at night worrying about the bugs that they may have introduced into the system that day.
Perhaps if the senior systems architect had to "stamp" the design of the system with his or her name and seal, and the senior systems engineer had to certify the systems implementation, then we would have people laying awake at night worrying about bugs.
I think a lot of software engineers don't lay awake at night worrying because they are consultants. They write their code, collect their money, and move on to the next project. I worked in-house at a couple of Telcoms and I did worry at night about bugs because I had a pager on my nightstand (and there is some law of the universe that bugs are only found at night, usually on the weekend).
I've seen both sides of this... in-house folks that just don't care (pager or not) and consultants who put every effort into each project they undertake. When you engineer a solution to a problem (software or otherwise) your name and reputation is on that solution. If people don't have a passion for the job they do, you will find the kind of issues Christopher speaks of (no matter what the job is.) The only way to cure that is in your hiring/selection process, consultant or otherwise.
Post new comment