He said:
As an infrastructure engineer, I have to adhere to the most rigorous standards, and follow well-established engineering principles. The software people seem to get away with murder - if I was as unprofessional as they are, I'd get sacked.
She said:
You hardware people just don't get it. How can we adhere to anything when the specifications keep changing? And anyway, who's going to meet the cost of engineering-in software quality? No one in this organisation, you can bet.
A very senior Microsoft official famously once said that if the company put any more time and energy into engineering its products, the effort would cost it lots more and would not lead to the sale of a single extra copy. If Intel took that attitude events like the public relations disaster that grew out of its refusal to admit a 1994 flaw in its original Pentium chip, and the more recent multimillion bill for recall of Pentium III boards, would be the rule, rather than the exception. The company would die in the water.
The point is not that one approach is wrong nor the other right; it is that there is probably no more dramatic illustration of the gigantic chasm that commonly exists between the hardware and the software people on any project than the differences between a Microsoft and an Intel - and it is a chasm that can irreparably harm a project.
"Software developers are from Pluto; everyone else is from Mars,"says Cutter Consortium senior consultant Jim Highsmith; " . . . software engineers are considered weird by Â'real' engineers."In an industry where so many people spend their professional lives sitting at a desk interacting more with their computer than the human beings around them, the gulf in understanding between software developers and "real engineers"can severely damage project health.
For instance, consider the NASA study showing that 4 per cent packet loss translates to a 50-75 per cent reduction in user handling capacity. From the perspective of a network engineer designing a network infrastructure, that 4 per cent packet loss might seem a small thing - 96 per cent of packets do get through, after all. On the applications side a user might see the issue very differently: a 50 per cent reduction in their handling capacity will certainly lead to downtime and adversely impact on the bottom line. Unless the network engineer and the software engineer can be brought to understand each other intimately, such gaps in understanding can cause real project harm.
Approaches to the issue have been varied, and have met with variable success. For instance, writing in the Cutter Edge, Highsmith observes that many companies face the problem that while they have established cross-functional hardware teams, their software groups continue to be separate. If the development approach is a traditional upfront, plan-driven one, he says, this functional separation seems to make sense: the software group has its requirements and just needs to build. The reality is different. In real life such separations cause continuous conflicts as crunch time approaches when hardware and software must be integrated.
The simmering professional conflict is only exacerbated by the fact that hardware and software engineers have a poor appreciation for each others' issues. Even the language is different, Highsmith notes. When electronic engineers working with a circuit board layout define a "module"with well-defined interfaces, they intend that the interface remain stable. Software engineers consider modules to be variable.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.