We embedded people are concerned about meeting all those stringent deadlines as well as debugging our systems which steadily increase in complexity. I’ll write some of my thoughts concerning those topics and some more in a series of articles. Send me your comments and questions. I’ll post the most interesting ones here.
But now let’s start talking about bugs.
By Robert Berger
Development Cycle
Last time we talked about the working environment and the 80/20 rule. How about you? Do you introduce loads of bugs because your office sucks and you are interrupted all day long?
Let’s see what else might contribute to your bug rates by looking at the typical development cycle. Traveling the world and visiting companies as a consultant I observe many people applying the good old waterfall model.
Requirements, design, coding, testing, maintenance and from requirements to maintenance it might take a couple of years. I know it all depends a lot on the domain you work in and in case you are into high security projects which last for many years the waterfall might even work.
But for most other projects marketing usually wants new features every couple of months and in case a “big customer” comes along you might need to drop whatever you are doing and jump to whatever he/she wants. Besides changing requirements you have to cope with the psychological factor. In case you see a deadline far ahead in time the hard work will be towards the deadline and right now you might be tempted to deal more relaxed with the project. Because your boss wants you to crank code continously as a counter measure he/she comes up with a fake delivery date earlier than the real one. This might work once, maybe twize, but since we embedded folks are not particulary stupid it does not work forever. Next time we will ignore a real deadline just like a fake one.
What usually works much better, and what’s close enough to the idea of waterfall for your boss to understand, is called “EVO”[1]. You can imagine it like many small waterfall development cycles just lasting a couple of weeks each. Like this the hard work is kept high, since there are always deadlines near. Similar things are practised in Agile[2] approaches and where continuous integration[3] is an integral part of the development process.
By the way in case you have an integration phase on your project plan where you throw all the components for the first time together and all this towards the end of the project you can be sure that you will be delivering late. Maybe you should have a look at continuous integration to avoid the last minute panic.
References
[1] http://www.malotaux.nl/
[2] http://agilemanifesto.org/
[3] http://en.wikipedia.org/wiki/Continuous_integration
Author
Robert Berger consults and trains people all over the globe on a mission to help them create better embedded software. His specialties are trainings and consulting in the broad field of Embedded Software from small Real-time Systems to multi-core Embedded Linux.