A while ago I wrote a blog (now evaporated into the ether, unless of course, embedded.com chooses to republish it) on my frustrations in trying to design a product without any real specifications. Based upon some suggestions from my then editor, Rich Quinell, I formulated several rules of engagement to try and reduce the problems that arose. These are not intended to negate any of the other design practices as recommended by experts like Jack Ganssle, but when you work in a small organization, things like code reviews are just not possible.
- Never assume anything . The old saw that it will make an ass out of you and me is actually very close to the truth. Make sure you know what is expected from you, your employer and the different levels reaching the end user. Don’t assume that anybody is going to do anything that is implicit.
- Understand the project . This is not the same as the requirements for the project. Often your project is a small part of a larger enterprise and if you can understand what is going on your efforts will interleave much better. My experience has been that after a while the engineer at working at the lower level actually knows more of what is going on and how everything interrelates that the consultants. If you can get to this position, your credibility and negotiating strength is increased significantly.
- Get consensus . Taking your own approach without getting agreement from the customers (and I use that term very loosely) will lead to wasted effort and possibly delays in the delivery.
- Keep the customer informed on progress . It is much better for the customer to be in the loop rather than spring the delay on him the day before delivery. Often this has a knock on effect and your customer will get chewed out by his customer and he will be rather disgruntled.
- Learn the hardware . If you are designing with new technology, it is a great help to understand it in order to get the best performance possible. Of course there is a learning curve, but any study ahead of the project is bound to factor in your favor.
- Learn the development environment . The same is true as with #5.
- Marshall your test equipment . Make sure you have everything you need to test the project. Even sending something for calibration in the middle of a project can delay your progress.
- Make a plan . Even if it is only for yourself, look at the different steps you have to take to make the project a reality. Include tests and milestones so that you can estimate when you will need input from others, test equipment, and validation of proof on concept.
- Always verify the collective wisdom . Many times approaches that are suggested are nothing more than scared cows that will delay your project at best and will not work at worst. Ideas and concepts are often gut feel by people who have no knowledge of how anything electrical/electronic/mechanical works (like sales weasels).
- Document everything and try to think you are writing for someone else . This serves several purposes. When you are debugging a problem, especially intermittent, it is helpful to go back to see what actually happened. It helps if you can actually read your own writing and understand what exactly you were thinking. Also it helps to keep track of what the customer has asked for, what has changed and the conflicting requirements that arise from that change, and how the customer responded to that. Sometimes that is only for your own self-satisfaction because “the customer is always right” and “money talks”.
- Simulate the system . Use this to establish unlikely conditions and to hold values that are normally transient. This helps to debug the system and establishes so “what-if” questions that hadn’t been thought through.
- Notwithstanding #11, test under real conditions and with real equipment . Simulations may not reveal complex and unexpected interactions and all the presumptions that have been fed to you will be tested out.
- Test on final equipment . The test equipment, by Murphy’s Law, will differ in at least one critical aspect that will stop your solution in its tracks.
- Identify the exact issue . When someone describes a problem it is from his perspective and often not the real problem. Find out what exactly happened. Get to see the problem Reproduce it. Track it with the best instruments you can find.
- Beware of unintended consequences . Retest completely when any change has been made. A simple change in one piece of software can have catastrophic consequences to another. These tests can often take a lot of time, so a good subset would be helpful.
Of course all of the above is meaningless if the powers that be accept the project without any provisos and contingencies. Even having experienced the meltdown of several projects and with my checklist, I recently went through a similar debacle. Our contact thought a rotary BCD switch was a potentiometer, said we only needed one setting when he wanted four and couldn’t provide a load to test the unit on. I don’t mind the predictable outcome as much as it makes me seem incompetent when I have done everything in my power to prevent the conclusion. I hope you don’t have these same issues and that somewhere there is a saner world.