Author: James R. Chiles
Publisher: HarperCollins, 2008 (eBook edition)
We live in a complex world of machines that we've built for ourselves. While machines and their connected systems exist for our needs and service, they can sometimes go terribly wrong. They don't behave the way intended. Once they go rouge, they can't be controlled. What the world then sees is the fallout from a disaster no one expected. This book takes the reader through dozens of such disasters. The author narrates these disasters almost as if they're happening beside us. He explains the technical details. He describes the frantic attempts by those at the scene working on the dangerous edges of technology. In the process, he fills us with a sense of awe and respect for technology.
Yes, those of us who take technology for granted will be more respectful of it once we read this book. Going by the promise of Murphy's Law, many things can go wrong. The author notes that if such a law exists, we should be seeing lot more disasters. In reality, for every disaster that comes to front-page news, there are probably many more near misses that somehow did not run away to a disaster. Failures are likely and they do happen quite a lot in many systems. Due to built-in redundancies, good design and fail-safe mechanisms, many of them are caught early. But many small failures linking up together lead to a disaster. The author states, "A disaster occurs through a combination of poor maintenance, bad communication, and shortcuts. Slowly the strain builds."
Getting up to speed quickly
Even if you are a narcissist, chances are that you will spend a lot of your time reading other people's code than admiring your own. The primary reason is that we have come to depend a lot on open source software. Technology is progressing so fast and in so many different directions that writing good software is really a collaborative effort. As individuals, we will make the parts that others can use. We will use parts that others have written. Even if we create an application from scratch, it will most likely depend on libraries and interfaces written by others.
A lot of times we may not need to look at other people's code because we will use their work through defined interfaces and APIs. But what happens if we wish to improve that code? What if we discover a bug and wish to fix it? What if the APIs are not adequately documented? There's also the case of mergers and acquisitions. It often happens these days that you're suddenly staring at code your employer has just acquired from another company. The original team may be unreachable or busy with higher priorities than help you out. Then there's the case of outsourcing work. If your team has just accepted a project to maintain legacy code, you have no choice but to understand it at source code level. So how does one go about deciphering code others have written?
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.
Lessons from a data visualization project
Data analytics has been a hot topic the last few years. Usually it is discussed as part of a bigger framework or technology. Big Data, Internet of Things and Machine Learning come to mind. Just as equally important, but almost taken for granted and hence not widely discussed, is the art of data visualization. I label it more as an art than a science because there are no set rules as to how data should be visualized. With so much data available to us and so little time to process them, we need effective data visualization techniques to unlock the hidden value in data.
The science of data visualization talks about tools and formats. The art of data visualization is about the aesthetics. It's about choosing the right colours for appeal without distracting the viewer from the insights within the data. It's about achieving the right balance of graphical elements on the chart. It's about giving just enough data to engage the viewer but not giving so much that the viewer is overwhelmed with too much data. There's of course an area in between where art and science overlap, something that's not easy to characterize. What is an art to one developer or creator may be a science to another.
Author: Elaine Chen
Publisher: Elaine Chen, 2015
Bangalore has been a start-up hub the last couple of years. It's not uncommon to find students graduating not just with a degree but also an idea for a start-up. I have met such fresh engineers at maker fairs, exhibitions and demo nights. They have a prototype that's usually on display. The prototype works. Next, they tell me that they are going to market or scaling up. Often they sound as if prototyping was the toughest part and the rest is merely tying up loose ends.
I guess this perception comes because they have not been exposed to the challenges of making a product or what it entails. They have no knowledge of the manufacturing process. They might have solved many technical problems in the prototyping phase. This gives them a sense of achievement and a false sense of completion. One of the greatest myths in the mind of an uninitiated inventor is to assume that the road from prototype to product is a simple straightforward step. Engineer and product management consultant Elaine Chen explains otherwise.
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.
A Personal Case Study
In a previous article we introduced the initial steps of designing a web app. We focused on requirements and wireframe diagrams. In this article we'll look at the implementation. In fact, one question that comes to mind is when should implementation start? Should we wait for design to be 100% ready or should be jump into implementation on day one?
Most people who have a decent experience in implementing web apps know that no one can wait for design to be 100% complete. During the process of implementation, developers may come across flaws in the design. They may encounter ambiguities. They may at times find that translating the specified design to code is tough given their current tools and expertise.
A Case Study from Personal Experience
Exactly a year ago I was approached by a friend to design and develop a web application. I don't take up projects unless I like the idea and see a potential opportunity in the market for such a product. His idea was novel. A quick survey showed that no similar products were out there. Ones that did something similar came from the background of generic ERP and CRM systems. They were not in any sense a web app the way he had conceived it. They were heavy and not user friendly.
We knew from the start that the focus had to be on user experience. The rules of design in this space are quite simple: keep it simple and eliminate clutter; present high-level summaries; make important items easily accessible; don't use fancy terms; keep navigation and structure intuitive.