Actions
Forum Thread Details
  • Replies 3 replies
  • Subscribers 491 subscribers
  • Views 499 views
  • Users 0 members are here
Related

The Ten Coding Commandements - for bug free software.

Former Member

I have been on a quest to educate people about the quality of software in embedded systems for about three years or so now. As part of my travels to various companies I have compiled a list of ten things design teams should be doing if they are serious about reducing the number of bugs they have in their software. It's a quick and easy litmus test on the effort your company goes to to ensure the software you write is bug free. A high score means you are doing the right things whilst a lower score suggests you software in vulnerable to hidden bugs. Take the test at the end and post a reply with some basic feedback for the other bloggers.

http://www.youtube.com/watch?v=A78saoX2msM

 

The basic presentation without the naration is available here as an attachment also.

Attachments:
image60 The Ten Coding Commandments.pdf

  • Slide 5 ("Version Control") doesn't mention version control of the tools (compiler, etc), which is almost certainly a very good idea as well.

     

    One wonders whether the ideal sized environment, where customers, marketing, development, and test are all big and cluefull enough to be effective at their portions of the process, while still being small enough to effectively communicate with each other, actually exists except for brief instants in time :-(   http://www.businessballs.com/treeswing.htm  and  http://xkcd.com/844/

  • in reply to WestfW

    Thanks for the feedback. Yes- version control of the tools is important, especially the compiler. Did you score your own company/last project if so I'd be happy to  see what you did get.

  • in reply to Former Member

    With the "big company" shoes on, I think we at least claim to do (and spend a lot of time TRYING to do) everything except unit test at the single function level, which I don't think scales to the size of our product(s.)

     

    Your commandments are a bit hard to apply to the class of "embedded system" where the base hardware is a desktop class cpu running linux or windows.  Test cases in particular multiply to infinity, and our biggest problems are due to unforseen interactions.

     

    There's something missing WRT the differences between a new product, a new feature, and a new bugfix, but I can't quite put my finger on it.

     

    The XKCD cartoon is particularly real; whenever the code is perfect and exactly matches the requirements documents, it seems that it's not what the customers wanted after all.