Bugs that turned out to be expensive
Some of you may recognize the picture above, of a moth taped to a log book in September 1947. The moth was found in one of the relays of Harvard's Mark II. Although the word "bug" to describe a software fault had been in common use among engineers for some decades, this story is often mistakenly quoted as the origin of the word. If you're an engineer, you will agree that every system has software bugs. It's impossible to design and bring out a perfect software product. Fundamentally, the world itself is imprecise and unpredictable, and all software systems interface to the real world in one way or another. Some of these bugs may lie dormant and never see the light of day. Some others may occasionally arise and disappear without serious consequences. Some others, when they become active, cause catastrophes. It's the last of these that deserves our attention.
An anecdote is in order. India's Income Tax Department has a Excel file where you can enter your income details. The macros in the file will calculate the tax that you have to pay. Some years ago I used this software and submitted my tax returns. Many months later I got a notice to pay pending tax of ₹ 1! Clearly, a rounding-off error somewhere: macros in Excel did not agree with IT Department's enterprise software. Although this bug did not cause any serious damage either to me or to the government's coffers, history gives us far more spectacular failures due to software.
Authors: Jack Ganssle
Publisher: Newnes, 2008 (Second Edition)
When I picked up this book, I half expected to read about a serious subject written in a serious textbook style. Within the first few paragraphs it was clear that this book surprises and interests, not least by its almost chatty informal style. It's a book written by an engineer for engineers. It's a book written by a practitioner with many years of solid experience. The author is not presenting here a theoretical framework or a wish list. He is rather condensing many years of experience from which readers can directly benefit. He gives loads of tips and tricks that engineers can start applying in their daily work.
The relevance of this book is of course obvious. Embedded systems are everywhere: in home electronics, in personal devices, in industrial automation and increasingly in tiny devices that are going to come in their billions as part of the Internet-of-Things. Now more than ever firmware developers need to learn from the experiences of others and adopt best practices. To learn from self-experience through mistakes and mishaps is something neither engineers nor their employers can afford.
Patience and Perseverance are Essential
It's been nearly 20 years since I debugged hardware wiring and circuit boards. While there are some common skills to both hardware and software debugging, hardware presents some particular difficulties. You never know where the problem could be until you isolate the sub-systems one by one in an effort to get to the root cause.
All these years, I've been a telecom engineer. Only recently have I been dabbling a lot in simple electronics, more at a hobbyist level than anything else. Part of this is triggered by the accessible nature of low-cost development boards such as Arduino, the dropping cost of electronic components and plenty of open source code out there. Indeed, anyone could get into electronics these days with practically no knowledge of theory. It's possible to learn by just doing simple experiments.
Definition and Attributes
This morning I did a search for test frameworks. I was surprised to find that none of the matches from Google gave a satisfactory definition. Some were vague. Others were probably more precise but did little to clarify. A few articles explained the different types of test frameworks out there. In this blog post, I hope to give a better explanation. The intent is to lay out in simple language what constitutes a great test framework.
The dictionary definition of framework is useful as a starting point: a basic structure underlying a system, concept, or text. A testing framework gives test engineers a set of components and interfaces so that they can focus on writing test cases rather than worry about many administrative tasks. These administrative tasks may include among others initializing a test, executing it, checking expected behaviours, catching unexpected behaviours, composing test suites, and reporting consolidated results.
Oscilloscopes, analyzers and software
I had a chance to attend the Test & Measurement Innovation Forum yesterday, organized by Tektronix. I haven't been doing a lot of hardware testing lately except for basic current and voltage measurements using my humble multimeter. But complex systems need sophisticated equipment. Measurements have to be precise and the results must be presented to the user in an easy to understand manner.
Precision measurement is getting tougher with each new generation of devices that are released into the market. Systems are migrating from mere 10Gbps to more than 100Gbps. This means that the bandwidth of the test equipment must be higher, short rise times and minute jitter must be measured accurately. In some cases, such as LPDDR4 memory, even the probes have to evolve so that signals can be tapped out cleanly.
Where testing precedes development
When speaking to people who code, I have noticed a sharp divide between people who write tests for their code--also known as Test Driven Development (TDD)--and those who do not. In the former, the coder will generally write a test in the same language for each unit of functionality they intend to add to their project. In the latter, the coder will rely purely on outputting to the standard output with a 'print' statement or some sort of logging functionality.
Refactor before it's too late
I read an article, or perhaps a job description, a couple of days ago that talked about programming in a high-level language such as C. It surprises me to come across people still referring to C as a high-level language. Perhaps this was right back in the 1970-1990s but languages have come a long way since then.
Experiences from the front line
This is the final article to conclude two previous articles on the topic of building web apps. We looked at the process. I hope the steps I sketched will ease your work and enable you to roll out the final product faster. Ultimately every developer wants to be proud of his or her work without having to lose sleepless nights or end up with a nervous breakdown.
Despite experience and all the advice one can accept from others, each project is unique in its own way. There will be surprises along the way. There will be pitfalls, mistakes and wrong roads taken. In this post, I will share some of these experiences.