Friday, September 28, 2012

Are Code Reviews Still In Vogue?

I have seen a significant drop off of companies conducting code reviews, which is unsettling because code reviews are still extremely valuable.

The code review process is challenging, and real-time embedded systems have the additional challenge of software and hardware interfaces. That is why I recommend adding a hardware designer to participate in the code review. It can really help to solve problems quickly that may arise during the review.

I have heard Management's reasons to forgo code reviews:
1. It ties up precious resources
2. Not sure how to conduct one properly
3. Might upset a few of our developers
4. The meeting becomes an excuse to attack someone
5. Not on the schedule

But I feel that in spite of all the trouble it may entail,  the goal of creating high-quality, sustainable, maintainable code in a timely manner is well worth the effort. I have found design reviews and code reviews to be invaluable tools to improve the actual quality of the software, stimulate growth, enforce coding standards and find bugs early.

In my experience, having led code reviews and having been a member of peer teams reviewing code, I always felt that it was a positive learning experience. Oftentimes simply asking the developer basic questions and allowing them to explain their thinking leads to amazing results.

Are you using code reviews as an integral part of your embedded development experience? What challenges are you having?


Monday, September 24, 2012

Changing to a New Embedded Development Platform

I imagine that for you, as for me, changing to a new firmware development platform is a serious undertaking.

We have all used plenty of development platforms and software development kits (SDKs) from various manufacturers in our careers--and since most of them share a great degree of commonality, we are comfortable with changing to a new embedded development platform. However, I find that the significant challenge lies in discovery of the differences between what we have used and are familiar with and the nuances of the new platform.

Changing to a different development platform is typically accompanied by a change in chip family and / or manufacturer. I find that truly mastering the new platform involves both reading through the reference materials while working with the new tool kit. (For application programmers, the creation of the ubiquitous "Hello World" software program is still the typical starting point.)

But embedded programmers face a different set of challenges. We actually have to get the hardware working first for any software to run (i.e. the Board Support Package (BSP) and the accompanying evaluation board).

In many embedded development projects, product hardware is designed and developed in parallel with the new firmware. Since the product hardware is usually based upon reference designs from the chip manufacturer, making sure the SDK's board support package works properly with the manufacturer's evaluation board is a natural first step.

I start by installing the SDK on my development computer, getting it operational and integrating it with the source control program that I plan to use. Since a typical microprocessor or microcontroller can be configured in so many ways I focus on modifying the BSP to get the evaluation board operational as close to the final product configuration as possible. Once I can demonstrate that I can configure the BSP to control the evaluation board specific hardware (e.g. LEDs blinking, testing memory, exercising I/O, and communication via USB, Bluetooth, RS232 or LAN) then I am ready to turn my attention to developing the product firmware. Often the initial firmware evolves to the boot-up diagnostic software for the embedded product.

What tips or process do you suggest when transitioning to a new embedded development platform?


Wednesday, September 19, 2012

Why Products Fail

It’s heartbreaking to see a product fail, especially when it could have been prevented.

There are typically two types of product failure. The first I call Field of Dreams -- “if we build it, they will come.” I’ve seen plenty of cool products built without a marketing, sales or distribution plan, usually by techies with a great idea and impressive skills, but not much business sense.

The second scenario might be harder to see. This is when there’s a real business need and a real market, but for whatever reason the company can’t satisfy it. Whether it's the inability to get the product out the door (scope creep), or a released yet inferior product, it’s painful to see a real opportunity missed. Especially when you know it could have been prevented.

When I talk with entrepreneurs, the questions that I ask typically go in one of two directions. For the techies, the questions are about business plans and sales and marketing strategies. The business folks seem to have all of that figured out, so I usually just talk about the testing and support of their product.  It’s important to know what you don’t know, and some gentle questions can get you there.


Wednesday, September 5, 2012

The Value of a Startup Mentality in Large SW Companies

Many of the large companies I work with, and have worked for, are trying to figure out how to create an entrepreneurial culture in the fashion of today's successful startups. I think this is a fine idea, especially the modeling of two particularly attractive traits of startups.

1. Speed: They just get things done! There’s no long approval process, and sometimes there’s no approval at all. "Just do it" is the mantra. Of course, speed should never turn into carelessness, which can then turn into chaos.

2. Budget: I know one firm that has built one of the most innovative and technically challenging products I’ve seen in a long time using various open source products. In a big company, there’s often money to spend, and it gets spent, and often with much less successful results.

I’ve worked in both big and small companies, and there are advantages to each. The resources of a big company are nice, but for me, nothing beats the passion and resourcefulness of a startup.