by Robert Berger
robert.berger@ReliableEmbeddedSystems.com
Intro
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 to talk about bugs.
As promised last time we’ll see where bugs are introduced and countermeasures. In Peopleware[1] DeMarco and Lister reported about coding wars among 600 companies (1984-1986). In this experiment the same problem was given to programmers in various companies and the results were compared. The best were 2.5 times more productive than the median and 10 times more productive than the worst. People from the same organization were performing equally bad/well. It was not a matter of the programming language, not a matter of experience (for people working more than 6 months as programmers) and not a matter of salaries, but the working environment. What makes a productive working environment? How about office space? Australian scientists found in 2009 that open plan offices make workers sick[2]. There is lower productivity and higher stress due to noise. This means a dedicated quiet workspace with a door would yield much higher productivity. Do you still think that your boss can not afford to buy you a nice new office with a door even if you would be 2.5 to 10 times more productive? How about time management? Find your most productive time of the day and make this your “quiet time” where no interruptions are permitted. Switch off the phone, indicate that you don’t want to be interrupted and start an interruption log if necessary to keep people away from your desk in your quiet time. Email was a great invention compared to the telephone, since it’s pull and not push. But only if you use it the right way. Switch off this annoying sounds and pop ups of your email client which come up as soon as new mail arrives. Instead read email only once a day, but not in your quiet time, and switch it off for the rest of the day. Why? Because every interruption throws your mind out of the state of “flow”, where you are productive, and you will need 5 to 10 minutes to find your way back into the “flow”.
This means with 6 interruptions one hour is easily gone. Remember the last successful and productive meeting you had? I can’t. So please call meetings only if they are really necessary. Your boss might not like to hear this, but it’s a good idea reduce overtime, since tired people make mistakes. In the 1950’s two of the early quality gurus (Deming and Juran) re-discovered the Pareto principle: 80% of the defects came from 20% of the products. 20% of the causes result in 80% of the defects. The 80/20 rule says, that 20% of the tasks you do account for 80% of the value. All you need to do is to figure out which those 20% are and adjust your priorities accordingly. For your embedded system this means that 20% of the system will give you 80% of the payback, all the rest is bells and whistles.
What’s the moral of the story? If you are the boss tell your employees that you’ll not pay them more since the coding wars indicated that money was not significant for productivity. If you are an employee tell your boss that you want a bigger office with a door which you can close on demand in order to increase your productivity. To wet your appetite for the next article have a look at the picture. It already indicates where more bugs are introduced. Stay tuned!
References
[1] ISBN-13: 978-0932633439 – Tom DeMarco, Timothy Lister – Peopleware
[2] http://www.news.com.au/business/story/ 0,27753,24906913-5017672,00.html
Author
Robert Berger consults and trains people all over the globe on a mission to help them create better embedded software. His specialities are real-time systems as well as embedded Linux.
http://www.ReliableEmbeddedSystems.com