Questions That Provoke Innovation

One of my LinkedIn contacts posted an interesting article about innovation recently. It got me thinking about how this might be used in process improvement.

While there are well known practices to address many of the common issues with poor quality software development, sometimes there are challenges implementing them in specific environments. For example, while it is ideal to develop tests and test products as they’re being built, sometimes we find that doesn’t happen and testing needs to be done after the fact.

Sure, you could just start writing all the test cases from the requirements docs, but that’s a long road. And what if there are no requirement documents? The product still needs to be tested, and in a reasonable timeframe with a reasonable set of resources.

Asking “How might we…” can unlock all sorts of creative options.  One company I work with is using Google Voice accounts to fill in as “people” when testing their software. Sure they don’t all respond, but it’s a great start to put a little more load on the system.

How might you come up with a solution for some of your more intractable problems?

-Judi

Doodle -- A Cool Application

Every so often a web-based application really catches my attention. This time it is Doodle, a simple and innovative scheduling application. It is ideally suited for coordinating a meeting or event when more than just a couple of people are involved. No more back and forth emails due to Doodle's voting mechanism. Very cool.

I often wonder what makes a particular application so attractive while similar ones are not. Of course there is no easy answer and it is very subjective.

For me the application needs to:

-Do one thing and do it well
-Be easy to use
-Be accessible from anywhere at any time
-Be offered at a "reasonable price" (not necessarily free)
Companies often cast a wide net when designing new products. The thinking is to add as many features as possible to make the product desirable to a large audience. But I prefer to narrow the focus and go deep in implementing the core functionality. I believe if you focus on end user interaction and then make the product easy to use you will have a winner.

Please share your favorite application with me.

-Gary

October Is Manufacturing Month

Here in Connecticut, October has been designated as Manufacturing Month. And since Advanced Decisions helps companies develop new products, many of our clients are manufacturers, giving me the opportunity to observe many of their operations firsthand.

And don't be fooled--manufacturing is not the dirty, dark and dangerous industry that it used to be. It's very high tech.

Manufacturing supports the economy in ways that other fields can't come near. Did you know that for every manufacturing job created, an average of 2.91 jobs in other sectors are created?

So during October, take a moment to learn more about 21st century manufacturing. It provides great jobs, with great pay, that require skilled workers. Groups like CONNSTEP, CBIA and NHMA are all sources of information that provide various programs to educate the general public about modern manufacturing.

-Judi

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?

-Gary

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?

-Gary

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.

-Judi

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.

-Judi