Practical guidelines to Indian engineers
Many engineers in India are working side by side with engineers from other parts of the world as part of global design teams. Yet even the simplest of electronics that we see around us has little or no connection with India. Why is it that a country that produces top engineering talent good enough to work with the best in the world looks like just a consumer, rather than a partner, in this global industry? Why do we not see a large number of electronics products that are ‘made in India’ or ‘designed in India’?
Obviously, there is no single or simple answer. Undoubtedly, several other countries have done a lot more to promote their industries. However, in this article I stay away from the policy aspects and approach this question from a purely engineering viewpoint. I take a candid inside look at the engineering community itself and explore where I think some of the missing pieces may be. I do not have any magic recipe for success, but I do make some suggestions based on my experience and introspection.
Learnings from Mobile Growth Bangalore Meetup
If you're a beginner to the world of mobile apps, you may be looking for someone to guide you. Developing an app and getting it out on the app store is only the start of a long journey. Many questions will hound you from the start. Why are so few users downloading my app? Why do many users stop using the app within a few days? Why are users not making purchases via the app? Why are users not using the app as often as expected?
Obviously, all these questions cannot be investigated at the same time. Where exactly should you focus your efforts and budget? How should the issues be prioritized? Is it a matter for developers, digital marketeers, product managers or customer support staff? Wouldn't it be nice if there's a community of mobile developers to share and exchange best practices? That's exactly what Mobile Growth provides.
Achieving Meteor 2-second rebuild time for £830
This was my purely hardware solution to the problem of slow Meteor build times.
When I decided to get into development I was adamant that I wasn’t going to run out and buy the latest and greatest in hardware until I actually knew how to code and knew what my requirements were in the long term.
So I went out and bought a used 15" Acer laptop for £150. It had the following spec:
- Memory: 6GB RAM
- Processor: Intel Pentium CPU 6200 @ 2.13GHz (Dual Core)
- OS: Ubuntu 16.04.1 LTS 32-bit
- Storage: 153.5GB HDD
With this setup, I saw rebuild times of 15-30 seconds (including the browser refresh) of a side project using Meteor 1.4, React and a Mongo-db instance with around 1500 records. I found these times to be excruciatingly slow when it came to making multiple changes to my code and waiting to see the results. You can see the initial version of the project I was working on here.
Analysis of a chat app and resolving the problem
A system in which concurrent events come in can affect behaviour depending on the relative timing of these events. Those working with embedded systems are probably familiar with this problem. Hardware interrupts come in at unpredictable times. One layer sends a message to trigger action from another layer. Data comes in via the wireless interface. A timer expires. How does one reliably handle all these events without taking the system to an unknown state? It would be worse if the system can't recover from such a state.
Real-time operating systems (RTOS) have some things to handle data synchronization, critical sections and race conditions. But can we have such problems in a web app? The answer is yes, as I found out recently when developing a "chat-like" app. The chat window of this app can be updated anytime by multiple users. When user A creates a new chat message, user B can also see it as long as the chat window is open. User B can then reply to user A's message.
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.
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.
Authors: Cole Nussbaumer Knaflic
Publisher: Wiley, 2015
I've been doing a little bit of data visualization for the last couple of months. The intent has been to get insights that could trigger decisions to add business value. While I've produced dozens of charts in the process, I've at times wondered if there's a better way. That's when I picked up this book written by an ex-Google employee who employed best practices in visualization to assist the HR department in their recruitment process.
If oil is considered as liquid gold, data is cyber gold. In the Information Age of today, data is perhaps becoming more important than ever before. Yet data remains just a bunch of numbers if we don't see past them to understand causes, patterns, trends, forecasts, dependencies, correlations and contexts. Yes, data can tell a lot about the systems and the world they represent. It's therefore important to analyze data. If data is cyber gold, it's not available in a glittering form. It has to be mined, processed and polished.