I often get comments from people wondering why I spend time every week writing these musings. Well; apart from the PR (for our engineering training) which helps to keep me off the streets, I actually learn even more from you guys with your responses.
1. Buy or Roll thy own engineering software tools
One of those perennial issues we get confronted with on a regular basis is the choice of buying your engineering software off the shelf or writing your own. Or at least cobbling it together from existing programs. Especially in today’s market when you may have more programmers available and the cost of the software off the shelf is often exorbitant. I have been down this route so many times and often made the wrong decisions. Obviously, if it is Word processing package or an engineering CAD package; you are unlikely to write your own; however it becomes a bit more debatable when, for example, you can purchase an industrial automation package already written for a particular plant or application and you can “simply plug it in” (well, that is what the vendor would like you to believe). I know we all have nightmares of being trapped in buying something which is rubbish and we should actually have gone down the hard road of writing it ourselves.
In essence, with engineering software what you are really after is:
- Availability – it should run and work smoothly with all your other tools
- Efficiency – minimal overhead meaning it is quick to operate
- Reliability – it doesn’t crash in a different hardware/software environment but runs without a hiccup
- Functionality – it should offer the functions you require – no more – no less
- Sustainability – it is constantly updated as new problems and situations arise with your systems
- Economy – it is not fiendishly expensive imposing a horrendous permanent $ burden on your project or product
It is virtually impossible for an in-house developed engineering software product to deliver consistently on all the above. Only a commercially produced package with tens or indeed thousands of iterations and many many installations can come up with this.
Why is an engineering software tool so hard to develop in-house?
A few quick points on this score:
- Commercial packages have been developed over a long period of time with many different clients and programmers – you are unlikely to have this with your own in-house developed software .
- You are exposing yourself to significant commercial risk. If you are handicapped by a tool that should have been purchased off-the-shelf you may be defocusing on your core mission. You may only need a small increase in productivity to justify paying for this commercial software tool.
- Others have been there and done it with a commercial package.
- You will achieve increased functionality due to wider usage
- What about the future? A software package doesn’t just stop but requires ongoing development. There is some degree of future proofing due to more support and R & D staff with off-the-shelf developed software. Somewhat questionable in today’s gloomy business world but generally true if you purchased your product from a reputable organization
- Your software developers don’t walk out of the door when they decide to move on
- Training new staff on how to use the package. You have to find someone to do this to a high level. Doing it in-house is often difficult.
- Ongoing maintenance for changes to your hardware and software environments. This has to be done as your needs change.
- And paradoxically – Customization. This is often quoted as the main reason to write the software in-house. But you may find the elements you require are already written for some other client in an off-the-shelf package.
So the standard mantra of our application being too different/special/customized for a commercial off-the-shelf tool is not necessarily always true.
Obviously in buying something off-the-shelf with millions of items sold as with a computer; one should bear in mind this sage advice:
If the automobile had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year, killing everyone inside.
Robert X. Cringely, InfoWorld magazine
My grateful thanks to one of those enduring electronic design engineers, Steve Ciarcia, who wrote hands-on electronics projects for Byte Magazine. This is based on an article by him and CMX-Systems on real time operating systems. Adapted to engineering software based on my mixed experiences.
Yours in engineering learning
Mackay’s Musings – 19th April’16 #596
780, 293 readers – www.eit.edu.au/cms/news/blog-steve-mackay