The Ideal Testing Mindset

I was working with a company a while back when one of the execs asked about softening test results so they didn't sound so bad. It made me realize that this exec, who was fantastic at marketing and selling, didn't fully understand the point of testing.

We get used to presenting things in the best light possible without lying, but with testing that mindset is counter-productive. Not that you want to blow anything out of proportion, but it’s important to be objective about testing.

First, how bad is this defect? This is where defined severity criteria work well – is data lost or corrupt? is the user unable to perform a critical function? is there a workaround? – all important questions when objectively evaluating defect severity.

Second, if there are areas that may not work as designed, wouldn’t you want to find out before your product gets into a customer’s hands? Yes it may take some work to fix it, but it’s going to need to be fixed either way. It’s better for your reputation and bottom line to fix it sooner rather than later.

Finally, it’s okay to have bugs early on in the software development process. That’s why we test. It is not a reflection on your product, it’s just part of the process. Just like all of us humans are flawed, so is our software. Fortunately (or maybe unfortunately) it’s much easier to fix our software bugs!

-Judi

Planning Your Next Embedded System

Since my philosophy on product development is so closely aligned with requirements definition, I don’t know how you can begin a new product development without creating a team first.

The team should not be composed of only technical contributors, but also domain experts (internal or external), stakeholders from various company departments, and finally the user community.

Once the team is assembled, you can begin to define product offerings, value, cost, etc. With timely marketing input up-front, coupled with manufacturing and service personnel voicing their inputs from the beginning, you can see a product concept emerge.

My advice is to keep the team involved all the way through development and deployment gaining feedback as you go.

So if it’s a question of technology or team, I always choose team first. What do you say?

-Gary

Smartphones and Service Technicians

Smartphones will soon replace laptops as the primary tool for service technicians.

Companies are realizing that laptops are expensive to maintain in the field, and no longer present a clear-cut alternative to a smartphone. In addition, many service personnel already have a smartphone with them at all times for communication needs.

Advances in core technologies have made smartphones quite capable for the diagnostic tests and troubleshooting of field service personnel. And new smartphones will still support legacy systems via USB adapters just as laptops do.

The main thing lacking is apps that integrate information for service technicians, which is no easy feat. The apps must be smart and collect data from various sources, including diagnostic test information, part procurement, customer and warranty information, and incident and problem reports to name a few. It is this total integration in a simple package that will be a game changer.

Please share with me your experience with moving your service personnel to a mobile platform.

-Gary

Process vs. People

Can a solid process support an inferior team? Yes.

Can a capable team overcome an insufficient (or inappropriate) process? Yes.

So which situation is more likely to be successful? In my opinion, it's the team every time. People trump everything.

Even though a good process makes a good team even more productive, a small team of high performers can do amazing things. The key here being a “small” team. Once you get past a certain size--I’d say 4 - 6--even the brightest superstars can become bogged down by poor communications and an inefficient working environment.

So if I had to pick, I’d pick the people. But of course, both is nice.

-Judi

Embedded System User-Interface Tips

I have often written about the need for requirements definition at the beginning of any embedded system design. However, I believe user-interface (UI) requirements are in a class by themselves, and thus deserve special attention.

During the conceptualization of the user experience I recommend focusing more on identifying user roles, workflow and informational content than on detailed screen design. Far too often I see a lot of effort devoted to specific graphics, color, font and button alignment before basic questions are even asked. I suggest starting with a representative selection of the embedded system's user community and the development team to address the following types of questions:

-Who are the target user(s)?
-What are their roles?
-What specific information is critical and actionable to each role?
-What information is simply helpful?
-What data is nice to have but does not need to be normally displayed?

Once the above questions are answered then the development team should rapidly create multiple versions of simple user interface experiences for the user community to evaluate. (Sometimes it may take the physical form of a software simulation when it is impractical to develop on the target hardware.)

User feedback gained from interacting with examples of possible user interface screens can provide invaluable feedback that will focus the development team on a specific implementation path. Once the path is set, then it is time to choose the right icons, fonts and colors.

Please share your tips for really good UI design.

-Gary

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

Designing a Robust Communication Protocol

In today's world of designing distributed embedded systems, it is imperative to design, document and test the communication protocol early on.

I recommend building upon the layers of protocol provided by the underlying architecture you have chosen, for example, TCP/IP, Bluetooth, USB, etc. If the underlying communication layer provides data integrity and delivery then it should not be duplicated in the application portion of the communication protocol. At a minimum, you are looking to have a low-level handshake between subsystems with assured delivery. Consider the following questions:

• Does the packet need to be routed?


• Does the sender need to know that the recipient received the communication packet?


• Is the data intact?

Now you can move to the business logic portion of the packet--the data payload definition--and begin to address these questions:

• Is there a command/response requirement?


• What is the general packet definition?


• Are there different types of packets?


• Is the packet size variable- or fixed-length?


• What are the physical units of the data transmitted?


• Was the packet understood by the receiving subsystem?

In addition to these questions, it's imperative that you list all of the possible error conditions. Ask yourself how you will be able to make them happen so you can test for robustness, which sometimes requires writing test applications to intentionally insert error conditions. Sometimes an external communication test device is the best choice.

There are many factors to consider, and this brief writeup is simply a starting point. What issues do you think are most important in building a robust communication mechanism?

-Gary

How Managers and Engineers Tackle Projects Differently

They say you can’t understand someone’s perspective until you’ve walked a mile in their shoes. Having been both a developer and a manager it’s interesting how the goals, desires and pressures on each differ. Ideally this wouldn’t be the case, but reality doesn’t always match up.

As a developer I always wanted to create the best work possible. If I could use cool new technologies and learn something in the process, even better. I took pride in the products we created, but was more focused on improving my skills and growing as a developer.

As a manager (and I noticed this more as I advanced more) I was focused on balancing competing priorities from customers (internal and external), delivering results as cheaply and quickly as possible, without sacrificing quality, of course, and shielding my development team from all the stuff that makes them less productive.

At times these differences caused conflict. Maybe trying a cool new untested technology is not the best business decision when you need to get something out quickly. Sometimes there was an opportunity to stretch one of your teams with an assignment, sometimes not.

Differing pressures are always going to cause conflict, but with a good dose of mutual trust and understanding they don’t have to be disruptive. As a manager I always tried to do my best to make sure my developers knew that I knew where they were coming from, and then tried to explain where I was coming from--and mostly it seemed to work.

What experiences have you had in this area?  I’d love to hear.

Judi

Curiosity Rover -- A Technology Powerhouse

I would be remiss if I failed to mention the biggest technology achievement of this year, the perfect landing and immediate operation of NASA's Mars rover Curiosity. In this stunning achievement of application of modern technologies, I want to point out this fine example of an embedded system.

Spaceflight Now has an excellent article on how the computer system was selected and built to work in the harsh Martian environment. Engineers at BAE Systems chose redundant and radiation-hardened PowerPC electronics to survive the thin Martian atmosphere. With 20% the CPU power of a modern smartphone, this device needs to be able to autonomously roam the surface for extended periods and be capable of sophisticated scientific experimentation.

It is interesting to note that there was not enough memory to store the landing software and the navigation software in the computer's memory. For the trip from Earth to Mars it had one mission, a perfect landing. Once the rover successfully landed and performed basic diagnostics the program memory was wiped and is currently being updated with navigation-oriented software. The new software needs to work flawlessly for a 2-year mission. There will undoubtedly be more updates but not a complete change of function.

For those interested in following its journey, visit NASA's official Curiosity website.

-Gary

How Process Improvement is Like Golf

Every time I’ve taken group golf lessons, the pro has started from the grip and gone through stance, swing and the whole works, laying out his best generic way to hit the ball. I recently learned of a golf school that prides themselves on the fact that they start where you are and help you improve the game you’ve already got. I love this!

This is the same approach I find most successful in process improvement work.  Every developer, engineer and organization has things they do well--and, as I firmly believe, if it ain’t broke, don’t fix it. Every organization has pieces of a process, which may not be ideal, but usually suffice for the time-being.

The key to keeping focus and gaining momentum in process improvement initiatives is finding those key leverage points that can make the biggest difference and leaving the rest for later. A golfer can only keep so many tips in their head, and a development organization can only change so many things at once without destroying their productivity.

Thanks for continuing to read. I love getting your comments back. If you have any suggestions for future topics, send them along, and I’ll do my best to cover them.

-Judi

Selecting an RTOS

Users searching for a real-time operating system (RTOS) for their project often get overwhelmed by the variety of commercial RTOSs available today. This variety nearly guarantees that an ideal system exists for you, but you finding it is a different question.

Embedded Computing Design published a helpful article about selecting an RTOS (this article was published a couple of years ago but the information is still relevant). An important note is that the article is written for selecting an RTOS for medical equipment requiring a high degree of safety and reliability. However, these are factors that should be considered for all embedded design applications, not just medical equipment.

One very important factor that the article does not discuss is RTOS cost. It becomes a complex decision when overall cost to develop the application is balanced against the direct cost of purchasing an RTOS. One needs to consider the initial cost to purchase the RTOS, per CPU license cost, associated third-party library cost with potential to save by reducing development and maintenance costs.

Check out the article and tell me what you think. I'll include your thoughts in a future newsletter.

-Gary

Do Business and Engineering Get Along?

A comment from David B on our recent blogpost on process fanatics got me thinking. He points out that there is often a “dichotomy in point of view and approach between technically focused people and business solutions folk. The more effectively you can get them to ‘walk a mile in each other's shoes’, so to speak, the better the odds of developing technical software solutions that meet--or even exceed--the needs of the end user.” So true!

I’ve been on both sides, and this is definitely apparent. Unfortunately, the solution is not as clear, but I think a respect for what each group brings to the table is a great place to start.

Business people think that engineers often look down on them because they don’t understand all the things the engineers do, and this makes them “stupid,” though in reality, they bring a lot to the table. Who would take that cool technology and turn it into dollars to pay those engineering salaries without all the other functions of a business?

On the other side, business people often think that engineers are putting up unnecessary roadblocks regarding what they can deliver and when. It’s easy to ask for the moon, but it’s not so easy to deliver it. Understanding a bit about the technical challenges of developing a new product would go a long way.

Do any of you work in a company where this problem has been solved or somewhat alleviated? What did you do?

-Judi

The Power of Negative Requirements

A requirement gathering typically focuses exclusively on what the product will do, how fast it will do it and the parameters in which it will operate. This is all important, but also, in my opinion, incomplete.

I like negative requirements because they stipulate specific features that a product or application will not provide. I find that by defining negative requirements a product development team and stakeholders can minimize confusion and the dreaded feature-creep. (There are enough stories of failed products and overwrought development teams to testify as to why it is not prudent to simply add a feature.)

When one puts a stake in the ground and states, the new product will not provide a specific feature and why, the conversation really gets interesting. From the development team's perspective, it helps to frame the product and handle change requests more effectively.

-Gary

Agile Myths

I ran across an article on Agile and loved it--not only because it mentions common myths about Agile methodologies, but also because it mentions common mistakes that aspiring Agile teams often make. I see too many individuals and teams using Agile as an excuse not to plan or document. That's not Agile--it's chaos.

Here's the article link: http://people10.com/blog/2012/05/13/agile-myths-answered-here/?goback=.gde_81780_member_114980795

Take a look, and feel free to tell me what you think. Thanks.

-Judi