One of the first articles that inspired me to start this blog was an article by Greg Wilson stating
Instead of software design becoming more like “real” engineering, we’re about to see the latter become more like the former.
To see what he considers “real” engineering, we need only reference his post of two weeks later, Without the Hot Air, in which he notes that
…almost none of what we call “software engineering” is actually engineering. I’ve worked with enough civil, mechanical, and electrical engineers to know how important back-of-the-envelope reality checks are to their disciplines. Other than figuring out how many servers you need to meet a service level agreement, I don’t know if such reality checks are even possible for software construction.
Having identified a fundamental difference between software and engineering design, Mr. Wilson correctly predicts (IMHO) that “real” engineers will inevitably become more like software designers in the future, rather than visa-versa. This will occur, he surmises, because new manufacturing methods, such as rapid prototyping and desktop manufacturing, can be manipulated via easily modified code. In comparison, traditional manufacturing methods require slow and costly changes to molds and tooling. As a result, future engineers looking to optimize mechanisms and processes (beyond the level possible with mass production) will increasingly turn to these newer technologies. In turn, they will need much stronger software skills, and will therefore turn to their software-centric colleagues for advice.
Five years from now, I predict that software designers who’ve been griping about never being given enough time or enough respect will be on the lecture circuit teaching their ID and IE counterparts how to be agile, live with chaos, and cope with design cycles measured in hours rather than months.
From what I’ve seen as a (rather elderly) grad student over the past five years, the programming skills of many engineering students are sorely lacking. I’d venture to say that the majority of mechanical engineering grad students with whom I’ve worked have no idea of how to use version control, or how to write a unit test. I am acutely aware of how easily a small programming error can alter the results of my research, and I suspect that a great many published articles unknowingly rely on faulty code.
Since I am studying in the area of feedback control, much of my programming work is in Matlab. Not a difficult language, and a heck of a lot easier to get started with than Java or C++. Still, while grading homework for an introductory grad-level controls class, I’ve come across some truly awful programming practices. This is not the fault of my fellow students. Engineering is not an easy discipline, and there never seems to be enough time to adequately cover the existing curriculum. As a result, engineering students are often never been exposed to the finer points of software construction. In many cases, programming skills are assumed but never taught—students are simply given a handout or two and expected to come up to speed on their own.
It would appear that Mr. Wilson has already recognized many of these same problems. He champions the Software Carpentry program, an effort to improve the software literacy of scientists and engineers. It is based on Python, rather than Matlab, but could probably be ported to a new language with few technical difficulties. (Finding the time to prepare for twenty-five hours of instruction is likely to be a much larger problem.) In any case, courses like this need to be a part of every engineering curriculum. Much of the physical world is going to be programmed, rather than fabricated, in the coming years.