I have found that on every project I have worked in the last ten years I have written at least one tool to make either the development or testing easier. Often in embedded systems you are working with specialized interfaces and very specific communication requirements. It can be a real boon to have a piece of software running on either a matching piece of hardware or a PC, which will help to validate your code. I'm not suggesting that anyone cause a project to run over schedule because you decide to spend six months writing a commercial test tool. [Sometimes a tool of this level is needed and a manager can be convinced to schedule the required time but it has been my experience that a day or two spent whipping up a command line driven tool or a simple Windows application can actually save time in the long run on a project's schedule. I would suggest that you get your supervisor's buy in before taking the day or two but I have found this is usually not a difficult task if you can explain why the tool is needed.

One of the strangest tales I have heard was about a new grad that was writing a moderately sized application for his employer. This employer had a fairly laid-back way of dealing with programmers, no weekly reviews just informal status reports. After two months this programmer came to the boss and said "I have finished writing the XYZ application but when I run it crashes, what should I do?" This particular individual left the company soon after this statement was made. Being a new grad he hadn't learned the one of the rules that makes software development a reasonable endeavor. Write a bit and then test what you've written. I try to make it a habit to not write code for more than two days before spending some time validating what I have written. Often this involves adding code to make a test of a specific feature testable but when done I don't have to worry about this specific feature in the future. Sometimes testing will involve linking the module in question with a test application to make the testing possible. Each piece of code is different but as a general rule, test it before you move on to another feature.

Another reason for testing it when you write it is the fact that it will never be as fresh in your mind as when you complete it. This however can bring up a nasty problem you will have to deal with. Often a programmer is the worst tester for software that he or she has written as the developer knows what the module in question is expecting as input and the testing will be based only on this known quantity. You must learn to play the "what if?" game with your own code. I often have to sit back and ask myself, "What if the calling software doesn't send me the right type of data or sends values that are out of the expected range?" This can cause some fast parameter checking code to be added to the module in question but that is all part of the game. I have had the good fortune to work with some very devious programmers who can devise some of the best test code around. If you work with some of these types, see if you can enlist them in your module testing. It will generally help you to build more bulletproof code. It also helps to make you a better programmer as nobody likes to be caught by the same type of overflow condition more than once.

Often the best resources any developer has is the people working on other parts of the system on which he or she is working. It can be quite useful to spend a few minutes discussing an addition or modification with these people as we all have to deal with our own blind spots. For myself it is useful to enunciate my plans as I have found that if I can't make my design understandable I probably haven't finished designing it yet. I have also found in myself a tendency to pick up weaknesses in my own designs when explaining them to others. It can't hurt to have someone ask a few questions about your plans and you might just find that it helps quite a bit. Again if you find that you work with people who are good at finding holes in a design, those are the people I would seek out.

One of the problems one runs into when called in to fix a show-stopper bug in existing software is the fact that often the original developer didn't follow this rule. Overly complex software, specifically in an embedded system can be a real nightmare. Often debugging tools are minimal if not nonexistent. In this environment working on code in which a developer has tried to make use of all of the bells and whistles of a language he or she has just learned or is still learning can create an incredible debugging headache. Remember, not only will you need to validate the software along with range testing your code, but at some time in the future someone else is going to have to understand your code. It may not be to fix a but it may be to add functionality to the product ten years after you have moved on to greener pastures. You probably don't want to write something so complex that you will be dragged back from your latest project to make these changes because nobody else can understand your implementation.

Adding a line or two of comments into the code as you write it can save yourself and all future programmers a ton of time when a change needs to be made to that code. Comments do not add any size to the executable and are a real blessing to anyone that needs to view or review the code later. This is another habit that you can get into, simply jotting down a note as to what a line of code does and maybe why it is done. I have worked on systems whose source code contained zero comments and I can state that these are the worst systems to make changes to. You need to spend much more time than would be normally needed to completely understand the software before making any changes as there often is subtle reasons for a piece of software to be written a specific way.