Engineering ain't engineering

The resources, guides and tooling available to the practising engineer have never been so abundant. But abundance brings dilution. As a limited resource, attention gravitates towards the rolling stone with the most mass. Eventually you don't even realise the homogeneity. And so it is with the most prominent discipline of engineering - software engineering. As Andreessen Horowitz put it in 2011, "software is eating the world". Indeed. The dilution is so complete that few would even notice that many uses of the term "engineering" relate specifically and exclusively to software engineering. This is a pity, since software has become outrageously popular due largely to its uniqueness amongst the engineering disciplines. For example, no other engineering discipline lends itself to such dramatically low reproduction costs, and delayed refinement. A bridge cannot be downloaded from the Internet, nor can it be upgraded while trucks are driving on it. These notions are as absurd as the notion that we ought to apply the well developed and documented best practices of software engineering to other disciplines of engineering.

The focus of EmpiricalEE, then, is strictly on electronic engineering. Being one of the physical engineering disciplines, this focus will relate well to embedded, electrical, mechanical and mechatronic engineering too. On the other hand, given the unique stakeholder relationships in public infrastructure projects, there may be less relevance to civil and structural engineering. But software engineering is a very different field. The attention, refinement and opportunities afforded by software engineering are a goldmine of lessons, but there is no straightforward conversion process - the discipline of electronic engineering must be understood on its own merits first to understand how the best practices of other disciplines can be applied effectively.