You probably didn't think that Dante was speaking to you when he wrote “The Divine Comedy," did you? Well, there's a lot to be learned from these sins as they relate to embedded software development and testing. We've all been tempted to sin, and many of us are guilty of committing one or more of these sins at one stage or other when developing the code for embedded systems.
At first glance, pride seems desirable. But, the human condition turns good pride in craftsmanship and quality into something bad. Pride can keep us from producing the type of code that makes for better profits. When we let down our guard down on basics like good code readability because we are so proud of what we did that we figure "no one else needs to know about this than me," we quickly find that we create difficult-to-understand code that is also difficult to maintain. This is not a call to more comments in the code. It is a call to unit tests, which are the best way to convey the sort of reuse that "clipboard inheritance" gives us. Our unit tests become the home to short and well-targeted code snippets that show how to use the code, and under what circumstances. That sort of humility is what we are looking for in the quest for sustainable engineering.
Greed is something that sneaks up on you. When developing embedded systems, many times, we are forced to think laterally to come up with a solution to a coding or testing problem that we face. Yet, we are constantly being seduced by various vendors attempting to sell us solutions to solve problems for us that we may or may not be facing. We must balance our actual needs with the solutions available to uphold product quality.
This is something that happens each and every time that we see others succeed where we fail in our product. We may lose the "first-to-market battle," but that doesn't preclude eventually winning the war for the hearts, minds and pocketbooks of our customers and the overall market. When envy occurs, we start to think "what corners can we cut to get this out the door quickly?" Sadly, one of the first things that we are willing to lose is quality. And diminished quality is what will convert potential lifelong customers into customers for the competing product. Good software development practices will help us turn envy into cash.
Wrath occurs when we forget to develop our code correctly. One can avoid the ugly face of wrath by using test-driven development (TDD). We can also test both white-box solidness as well as black-box functionality. It is also especially important to develop our tests as regression suites and to automate the build and test cycle in a continuous integration server environment.
We succumb to lust when we code for our benefit, rather than the benefit of the product that we are developing. We find that there are things that we want to use, such as a new and cool framework, which have one minor flaw. They don't fit into the product that we are developing. But rather than simply sigh and walk away, we scheme to find a way to make the framework needed for our solution, perhaps invoking the ever popular "future proofing" argument. We can harm ourselves by adding unnecessary weight to the code, and perhaps adding extra burden on limited hardware resources.
When we "gold plate" our code, adding extra and unnecessary code to handle "the next requirements" that we think will be coming, we bulk up unnecessarily. The problem is that we, as developers, really aren't all that good at predicting the future. But I can easily predict what your future will hold if you succumb to this temptation -- extra code to maintain which will drain testing resources. A simple application of Ward Cunningham's “YAGNI” (Ya Ain't Gonna Need It) is usually enough to remind ourselves to stay trim.
Sloth is present when we think that our embedded system software is incapable of being tested in any way other than in a fully integrated manner. In extreme cases, this means actual integration on the actual hardware that the system is destined for. While it is true that eventually we will have to perform final integration testing on the things that are actually delivered to the field, there are many different ways to test our code beforehand, using emulators, using test doubles and the like, before we commit to actual full integration. We can only make educated guesses as to the actual performance characteristics, and, yes, we won't be able to test all race and other timing issues, but we can still find an enormous amount of bugs in functionality using the low cost development environment before we commit to fully-integrated solutions.
By focusing on Agile and XP practices, we’ll be able to avoid committing these seven deadly sins. In our endeavor to avoid the nine circles of Dante’s hell, we will end up elevating ourselves to at least a workable solution, and perhaps we can ascend to the heavenly place in which our organization is performing well and producing profits.
Mobile devices call for tough embedded software testing