(this article is not just for embedded developers)
A few months back I was reading Doug Schmidt’s blog, on The Growing Importance of Sustaining Software for the DoD, and he made the claim
“although software does not wear out, firmware and hardware become obsolete, thereby requiring software modifications”.
It was a bit of a clarifying moment for me. Doug clarified two terms that I suppose were obvious, or maybe not. Software is this thing that can have a long useful life, where firmware is going to be regularly be made obsolete as hardware evolves.
I’d like to add to Doug’s statement:
although software does not wear out, it can be destroyed from within by unmanaged dependencies on firmware and hardware.
Think of all the code denied the potential long life of software due to being infected with dependencies on hardware.
By firmware I don’t mean just the code lives in ROM, as the definitions I found suggest. It’s not firmware because of where it is stored, it is firmware because of what it depends upon and how hard it is to change as hardware evolves, and hardware does evolve (pause and look at your for phone for evidence).
I have nothing against firmware, or firmware engineers (I’ve been known to write some firmware myself). But what we really need is less firmware and more software. Actually, I am disappointed that firmware engineers write so much firmware!
By the way non-embedded engineers, you essentially write firmware too whenever you bury SQL in your code or when you spread platform dependencies throughout your code. Android and iPhone app developers do it when they don’t separate everything they should from dependency on those platforms.
I’ve been involved in a lot of efforts where the line between the product code (the software) and the code that interacts with the product’s hardware (the firmware) is pretty fuzzy at best, fuzzy to the point of non-existence. For example, in the late 90’s I had the fun of helping to redesign a communications system that was transitioning from time-division multiplexing (TDM) to voice over IP (VOIP). VOIP is how things are done now, TDM was state of the art in the 80’s and 90’s. Whenever we had a question for the systems engineer about how a call should react to a given situation, he would disappear and a little later emerge with a very detailed answer. Where did he get the answer? From the worn out legacy code. The existing implementation had no separation between TDM and the business logic of making calls. The whole product was hardware/technology dependent from top to bottom and could not be untangled.
Take another example, of a brand new message processor/dispatcher that resides in the same file as code that interacts with a UART. The message processor was polluted with UART details. It could have been software with a long useful life. Instead the brand new firmware would soon be obsolete. The message processor was denied the opportunity to become software! And that is just not right!
I’ve known and understood the need for separating software from hardware for a long time, but Doug’s words clarified how to use the terms software and firmware in relationship to each other.
So engineers and programmers, stop writing so much firmware and give your code a chance at a long useful life.