This article was originally published in 2009. It is part of the ELMG redux series of articles that will be republished over the summer. Some additional material has been added. These articles cover subjects in and around digital control of power electronics.
“A room without a book is like a body without a soul.”
Gilbert Keith Chesterton
“A software engineer with a notebook used to be hardware engineer”
R and D Manager (anonymous)
Engineering documentation made easy.
How many of your company’s software and firmware engineers use notebooks to record their work? Does your company require that they have one? Is there a company wide recording system for engineering decisions? Are all issues tracked and resolved? Does the company require that they use the notebook as part of reviews and walk throughs?
Ever noticed that hardware engineers have note books but software engineers don’t? One software engineer told me that he did not need a notebook because his code was in subversion. When I asked him about how he documented the design of the code he just shrugged and said “The code speaks for itself”. Unfortunately for him and many software engineers poor code quality speaks louder.
A simple solution
We use Jira for issue and task tracking, Confluence for documentation and also have project notebooks. The first two of these systems are software as a service. The third is a red hardcover book.
Recently we have started to use OneNote from Microsoft and it is really effective.
Typically software engineering teams are more productive if some sort of personal recording of work progress is encouraged and enforced. Jack Ganssle’s recent article On Engineering Notebooks (seriously that is what the article is called) at embedded.com is a timely reminder.
Jack’s article describes the usefulness of notebooks as a record to be looked back at. When we write in our notebooks we are writing to our future selves. All to often we repeat mistakes and cannot remember what we did six months or five years ago.
Only you can prevent power converter fires.
Digital power more often than not has software in direct control of the gate drive signal of the power converter. This means that a software coding error can cause the destruction of the power converter. The same software coding error causes a blue screen of death on a PC or a scrolling glitch on your smart phone. In the case of a power converter the explosion may well cause a fire.
This explains why software for digital power is absolutely mission critical. Often the software for digital power is also safety critical. And so we take any opportunity to improve the quality of software.
Steps to improve software engineer productivity 200 percent
- Traceable requirements as per IEC61508 or UL 1998
- Enforce coding standards
- Jira for issues tracking
- Code walk throughs
- Code reviews
- Automated tools such as Lint
- and writing in a hard cover notebook.
Adding process improves productivity?
So how does this addition of all these overheads improve productivity? The short answer is that debugging is reduced to a tiny amount of time. Jack Ganssle has collected lots of information on what improves embedded software. One of the most effective first steps to improve software engineer productivity 200 percent is writing stuff down in a notebook.
Get 200 percent increase in software engineer productivity. Contact us here.