In my last post I ranted about the current state of software used to do engineering work, which I consider to be somewhere in between awful and abysmal. Now let’s ask – why this is the case?
Often it’s because engineering software is written by… Engineers!
Is it all that surprising that a program meant to simplify or automate some aerospace engineering calculations, under closer inspection of the source – turns out to be total garbage? Someone wrote the program in question to make their life easier, and barely got it to work, given the one semester mandatory numerical methods class they probably slept through. Hence it shouldn’t be surprising that the original author was completely ignorant of algorithms, data structures or anything resembling modern software engineering practices. Even worse, there is a high probability the program is written in some barely readable dialect of Fortran.
This problem in quality seems coupled to the essence of the problem the software seeks to solve. Who else is going to want a program that automates aerodynamics analysis besides an aerospace engineer? Certainly not your average Joe Doubleclick on the internet! Engineering software is an extremely niche market, which would likely seem a more difficult one to monetize than something aimed at a wider audience. Developers certainly aren’t jumping at the chance to write programs of this nature.
It also doesn’t help that these types of apps are very difficult to write given the amount of domain specific knowledge they require. Without an expert in the given subject area to assist in the design of the program, it will be hard to get it correct and verify the output. How will a developer know that the program they just wrote to compute the distribution of force in a suspension bridge is actually correct if they personally know nothing about physics, statics or mechanical engineering? It goes without saying that the potential consequences of mistakes here are astronomical. If a faulty bridge is constructed from designs created by a faulty program, or a wing section is designed incorrectly due to software producing bogus output – there is a potentially large monetary risk when the fabricated structure fails, and depending on the situation human lives could also be at risk.
Computer Scientists have been largely spared from this dilemma due to the fact they are extremely proficient at building their own tools. A modern compiler or operating system is easily as complicated as some of the earlier mentioned design scenarios, but the tools used to construct them are excellent. The GNU toolchain is a perfect example of this, extremely high quality tools that are open source and widely known in industry. It’s unfortunate that the other engineering disciplines haven’t seen the same gains in a tools windfall the software industry has, because its obvious to see how it has transformed the field.
Building better tools is hard and unattractive, but definitely can usher in some dramatic change. Computers shouldn’t be a distraction in engineering work, they should be an enabler. As software engineers, how can we make these problems manageable? How can we help our colleagues in other fields escape from this quagmire of terrible software?