Back in the early 1990’s, I worked at an engineering firm that developed very sophisticated communications receivers for surveillance applications. The projects were managed by electrical engineers, they ran the show. As the receivers became more advanced, the embedded control software within the receivers increased in size and scope. This led to an interesting conflict between engineers designing the hardware and software developers writing the software.

In general, engineering responsibilities for a given project were broken down along physical lines. For one project I worked on, there were four physical circuit boards in the product:

  • an RF board that contained the antenna input, mixers, and filters
  • a frequency synthesizer board that generated mixing signals and CPU clocks
  • an analog board for demodulation and power conditioning
  • a digital board with a high performance floating point signal processor, 32 bit microprocessor, and an Ethernet interface

Four engineers were tasked to that project, each working on one board. I was responsible for the digital board and some of the frequency synthesizer. One of the engineers acted as the lead, making sure all the pieces fit together. The software side was a different story. First they started with two software developers, then three, then five, then as many eight. The engineers could not understand why it took so many software developers when only four engineers were needed for the same project. There were claims by the engineers that the software guys were poorly managed, incompetent, or otherwise did not know what they were doing. The animosity was exacerbated by rapid improvements in hardware sophistication and complexity in each new hardware design. Engineers skillfully managed this complexity, whereas the software developers appeared to flounder.

I spent some time with the software guys. I soon came to realize that they were not at all incompetent, in fact they were quite intelligent. Why did the software require so many more resources and take longer to develop? Part of the problem has to do with the maturity of each discipline. Electrical engineering is more than 100 years old, computer science is on the order of a human generation. The engineering development process is well established, following older, but similar traditions such as mechanical and civil engineering. Civil engineering is thousands of years old, and they still slip schedules. Why would a very young discipline, like software development fare any better?

Engineering disciplines have had time to develop effective processes and standards. Wheels are reinvented, but the sizes are standardized. In software, the few widely adopted standards that exist are often poorly implemented and suffer from fragile interoperability. Automated testing is only now becoming a recommended practice, but still largely overlooked.

Another key difference is the disparity in formal education. You cannot hold the title of engineer in most firms unless you have at least a four year degree in engineering. As a physics major, I was permitted to enter the ranks, but with some explaining. In software, computer science degrees are often a rare commodity. Some even believe that a computer science degree is not practical or even necessary. Formal education takes a back seat to practical experience. In engineering firms, if you didn’t have a degree, the best you could do is be a technician.

Recently, I’ve been working on applications for PocketPC and Palm handheld devices. In both cases, new devices are available in the market every month, but the software and development tools just don’t keep up. On several occasions, a particular device we were planning to deploy on a large scale reached end of life and was discontinued by the time the necessary support software and our applications were ready.

A colleague recently told me that one engineer can keep several software developers busy. Our demand for greater functionality and interoperability will probably continue to fuel that maxim. Software is like the wild west, anything goes and the best shooters win. Unfortunately, it’s hard to achieve high productivity when you don’t have electricity or running water.