Thursday, June 28, 2012

My New Favorite Product

Pebble Technology in California has developed a watch using the new Kickstarter funding platform to raise over $10 Million by 68,929 backers. KickStarter is a direct offshoot of the JOBS Act, which enables entrepreneurs access to money from non-accredited sources.

I find the Pebble watch fascinating because it is one of the first products to act as a portable display device enabling hands-free monitoring of information on your smartphone. It is an intelligent e-paper wristwatch that communicates via Bluetooth with Android and iPhone devices.

And beside the fact that it’s just a cool product, what’s also interesting is that the company is planning an SDK to further customize the product to meet user needs.

Just thought I'd share my latest gadget-lust. Let me know what yours is.


Wednesday, June 27, 2012

Software Design Considerations

In continuation of my content series on software development process I’ve added a video on software design. It talks about important aspects to consider and also issues about designing in an agile methodology.

You can watch it at

Also, I'll be recording some new videos soon. Feel free to suggest a topic you're interested in. Thanks!

Wednesday, June 13, 2012

Thanks For Chiming In!

We’ve received a ton of great comments on previous blogs, and I wanted to highlight a few of the best.
On My Cure for Overambitious Projects, Mark W. writes:

Most people realize “Rome wasn’t built in a day.” As long as individuals feel that their input, requests, and concerns are receiving attention and are being listened to – and not just being brushed aside, ignored, or pushed off ad infinitum; if they know that what they want is in fact for the most part possible and doable – just not right now:

So true!  One of the benefits of some of the Agile methodologies is that not only do the users see functionality being added on a regular basis, but they also play a key role in sequencing new development.

In response to Are Your Error Messages Understandable? Doug Q writes:

It would be wonderful if error messages could go a step further (for those who are interested and click on “advanced details” or some such option.)

He goes on to suggest error messages could identify what’s wrong with the data entered to help the user solve their problem, and get information back to developers when necessary.  I think this is a great idea.

On Risk Management in Software Development, Bob K. suggests using Swim Lanes to identify risks in cross-functional communication/data flow.  He goes on to describe swim lanes:

The swim lane concept is one where each swim lane represents a function or department or division of a company. The lanes can also represent different companies. When information is transferred from one lane to another there is inevitably information that has to be re-transferred because it was not in the receiver’s required format, the initial content request was incomplete, the transfer schedule was incorrectly specified, etc.

Every time, in a project, there is an anticipation of data or information transference (especially across a swim lane boundary, a document should specify what information/data is wanted, the format of the information/data, the schedule for the transfer, etc. In simpler terms, there should be “expectation connectivity” between the sending and receiving functions.

This concept has merit and value in SW design when one program, module, subroutine transfers information/data to another. An interface spec should define this stuff. This approach is generally helpful in those environments that try to create re-usable SW and develop SW libraries for future projects/applications. The swim lane concept has value for any type project but recognize it is but one tool at the project manager’s disposal to bring the project in on time, within budget, and meeting the technical performance requirements.
What a great tool.  I can’t wait to try it. I think it will work just as well in process improvement initiatives.
Thank you so much for all the responses.  I’m really enjoying the conversation, and more importantly – learning a lot!


Tuesday, June 12, 2012

Are Your Error Messages Understandable?

Even though we like to picture ourselves as flawless developers, it’s important to address how our systems will behave when users encounter an error.

I usually break the possible system responses into 3 categories:

1. Bad: The system throws the user out, and potentially deletes the user’s unsaved work.

2. Slightly Better: The system doesn’t throw the user out or lose their work, but brings up a cryptic message in programmer-ese that just confuses the user.

3. Best: The system brings up an error message that’s understandable and informative, and also provides advice on how to avoid or fix the error.

If you hadn’t already guessed, I recommend the third option. However, this is also the most difficult to properly configure, because each system error must be linked to a plain-English explanation.

Emily Wilksa, a former technical writer for Microsoft, has written a helpful article on writing effective error messages. Click here to read it:



My Cure for Overambitious Projects

You’ve probably encountered clients that request an unrealistic amount of features to be included in a product. They’ll start by listing a few features that the product “absolutely must have,” which suddenly reminds them of a few more features, which then brings up more that “we probably should include.”

Meanwhile, your headache is growing because you know that such lofty expectations always fail.

Well, it’s time like this, before any of the development begins, that you’d benefit from splitting up feature requirements into two categories: essential and supplementary.

This simple action will save you enormous stress later on in the development process, because it forces both you and the client to agree on what is most important, and what can wait.

After you make the list, give a copy to your client, and keep one for yourself. Whenever an issue about including more features comes up, refer to the list and ask, “Is this truly necessary?”


Here's My Template for Subsystem Interactions

Subsystem interactions are a tricky part of embedded system development.

I’ve experienced many projects where team members are assigned to develop a specific subsystem, and though they succeed at their individual task, they overlook how their system will interact with the other subsystems, which can lead to a dysfunctional product.

This ignorance of subsystem interactions is usually found in a bottom-up design approach, but can sometimes be found in top-down designs, in which attention to detail for performance, error handling and test strategies are all lacking. (These are not the only important requirements but for whatever reason I find them most often overlooked.)

Anyway, to help you out, I compiled a simple Excel template that displays these categories for multiple subsystems. Click here to download it:

Some More Comments on Overambitious Projects

I previously asked readers to share their experiences with overambitious projects. Here were some of the replies:

Creative people always desire to create a perfect product. And it is very difficult to stop perfecting it… It’s not easy to differentiate between essential and supplementary features.

Also interesting fact from the “big science” molecular biology – the Human Genome project (that was also saturated with computation and programming). Finishing sequencing took as much time as the first 90% of sequencing work.

So true. There's an understandable amount of pride that creatives and entrepreneurs feel about their work--sometimes to their detriment.

And also this suggestion on how to handle feature-hungry clients

As a product manager, I have dealt with this issue many times.  It always helps to ask the client (internal or external) to estimate the additional sales that will occur if the new feature is added.  Invariably they either realize the answer is zero, or understand they have no way to credibly answer. No additional sales, no money for development. Simple but effective.

What a fantastic idea. It lets the client clearly see the value of each additional requirement.


The Value of Defect Prevention

Steve McConnell reported in 1996 that "early upstream defects generally cost 10 to 100 times as much to remove late downstream as they do to remove close to the point where they are created.”

So why is it that we spend far more time, effort, and dollars on defect removal than defect prevention? Because, sadly, preventing problems is not sexy.

Many programmers and people in general, love to be the hero. Finding and fixing that critical error provides a great adrenalin rush. But when you consider time-to-market or cost issues, this model just doesn’t make sense.

A few of my go-to defect preventative tactics include:
• Requirements reviews
• Design and Code reviews
• Coding standards
• Writing test cases and plans early
• Automated build and smoke tests


Embrace Change

I’m amazed how many developers and companies are reluctant to adopt modern technologies in their projects, especially when it could cut significant costs from the development process.

I even recently met a team who is still designing serial communication ports for their external interface. Ouch.

Thus, I'll focus my next few emails on development technology areas that have significantly benefited from recent innovations:
• Display technologies: highly integrated graphic chips and capacitive screens
• Wireless communications: near field communication, Bluetooth, WiFi
• Location-based systems: low-cost integrated GPS chips


[Video] 4 Critical Pieces of Software Development Processes

I just finished up a video explaining the most critical aspects of software development processes.

It's an issue that I'm fanatical about, especially because it involves basic software development strategies that can save companies tons of money and time. (And who doesn't love extra money and time?)

Anyway, the video is 4:23 long, and introduces the below topics.

  • Requirements

  • Design

  • Testing

  • Source Control



P.S. Let me know what you think of it!

Wednesday, June 6, 2012

Is Android Viable for Medical Devices?

I recently attended the RTECC Boston Conference and was not disappointed.

Of particular interest was the keynote address by Alan Cohen of LogicPD about the viability of using the Android operating system for medical devices.

I approached the conference with 3 key questions, which I've since answered below.

1. Why Android?

Android is a complete framework built on embedded Linux with a fully implemented GUI right out of the box. It can begin developing an application very quickly, is a terrific development environment to rapidly develop a proof of concept, and is highly customizable.

2. Is the Android operating system suitable for medical electronics?

Android is only suitable as an adjunct to time-critical or life-critical processing. It is not a Real-Time Kernel (RTOS) and therefore not suitable for hard real-time applications.

3. Will Android be relegated to display-only functionality?

Mostly, but relegated is too strong a word. It is ideal for user-interactive applications since, according to Alan Cohen, there is a convergence in the medical device world and the consumer world.

Some key Android points:

• Built on Linux

• Built-in power management module is non-trivial since it is geared to phone/data devices

• Application licensing can be tricky (the kernel is GPL license). Even though Android is free, some Android Device manufacturers nonetheless pay royalty fees to Microsoft?

• Android allows very easy creation of embedded Linux applications with GUIs



Monday, June 4, 2012

Creating Software Requirements Processes

It's hard to perfect your software development process without a solid requirements process in place.

I just finished up this video about software requirements processes that covers

  • How requirements are done in different software processes

  • Proper requirements formats

  • Who should be involved in the requirements writing