This phrase is a familiar, and everyone involved in firmware or software knows the familiar completion. That’s not what I’m writing about. 

I have been seeing lot’s of defects in both software and firmware lately, and I use lately very loosely. This isn’t a local phenomenon or a new one, but one that seems to be trending, fast, accelerating even, but not in the right direction. So if we don’t want a lot of unintended “features” in our software and firmware, what do we do?

I want to step back to the title, and consider different endings, that can hopefully begin the mindset change that can eventually reverse the trend. 

May 24, 2011

Everyone likes "new" and Apple is currently the master of the new that more and more people want, all over the world. And some only see just that, the compulsion to always buy the new product that Apple rolls out each year. I find myself yearning for these new products but tempering my purchases with my Scandinavian immigrant, depression-era-parents-bred values. But I do have an iPhone4, and a Macbook (but it's almost 4 years old now).

in the following 2 minute clip, Stephen Colbert eschews the depressing stories of the day (after reminding us of it all) to gush over his new iPad2, which to him is better than his original iPad, because it's thin, and has a camera (which he demonstrates with his mug). But even so, he is now wishing for iPad3.

A poke at us consumers, but Apple and Steve Jobs are not just about getting us to buy something that is new, but bringing the new/best "tech" to the non-tech masses in a way that it really can become part of their life. The following clip of Steve Jobs from decades back shows him talking about making the computer a bicycle for the mind. The logic is fascinating (not the the source code, the thinking).

And some still point to many of these bicycles adopters as just gullible consumers with more money than sense. When to make a point, the next clip is the epitome of gullible. (And yes, everyone in the clip seems to have an iPhone).

But the "bicycle for the mind" metaphor is much stronger than a simple April Fools gag (although the computers we now carry in our pockets can execute some awesome pranks). Bicycles are not hard to understand and use, but they take a little training. The mind must learn the balance and how to use the two spinning flywheels. And it isn't hard, but once mastered you can go way beyond pedaling and coasting. The next clip is one guy's demonstration, and if his bicycle was a computer he'd probably be cranking out iPhone apps.

Apple is praised not just for design but for function as well. What happens when design trumps function? Often great beauty, as demonstrated in the next clip.

But just as often questionable functionality. The phone shown below (go here for more pictures and info: mocoloco.com/archives/022683.php)

Like so often displayed by Bang and Olufsen in the past, the design can trump the performance and usefulness, but the simplicity of iPhone/iPod/iPad seems to have propelled B&O to create Beosound8, a beautiful presence and expansive sound even from the compressed digital feeds we all consume today.

And at $999 from Amazon it's not cheap, but most reviewers who took time to write agree that to them it was worth it, although one reviewer complained about the paper speaker cones, not what he expected for the price. (See for yourself if you want: www.amazon.com/Bang-Olufsen-BeoSound-8-Black/dp/B004BGTK14/ref=cm_cr_pr_product_top) 

So, what is my point? The thing we do is more than simply what we make, write, or say. It is how it affects the world and those around us. Be sure to ask yourself often "Why am I doing this?" and if you can't answer that question well, better start doing it different. Let your mind ride a bicycle.

Jon Pearson

Jack Ganssle asserts that since a Capers Jones study of late software projects showed that bugs were the biggest cause of late delivery, get rid of the bug list. This isn't as crazy as it sounds when you consider his justification that no one knows how long it takes to fix a bug, so there is no believable schedule when you have a bug list. To fix it, get rid of the bug list.

Really? Ya.

Ricky Gervais was interviewed in the Harvard Business Review (Ricky Gervais on Not Having a Real Job), if you subscribe to HBR you can read it, but anyone can listen to the 12 minute podcast. 

If your knowledge of this comedian is from the original The Office BBC TV series or his hosting episodes on the Golden Globesawards, the man on this podcast is NOT that man. And while Ricky did not specifically address what to do on your next embedded design, he did have some gems which can be applied to your project.

1) "Ask yourself 'Why am I doing this? What's the best that can happen?'" also ask "What's the worst that can happen?" Always critically examine what you are doing and why. What was a "good" idea at the start of the project or the start of the week may be a waste later, based upon the learning since.

2) "What matters is the work you've done" Take pride in your work. Don't be afraid to be recognized for it. Kinda goes without saying, though. Still.

3) "Write about what you know" was Ricky's response when asked why he did "The Office", but he also meant "write" about what other people know, as in everyone gets the office setting and situations. So on a project if your code and comments and design explanations aren't being understood, you missed your mark. Rewrite them for others, not for yourself. Especially if you don't wish to be fixing it for years.

4) "Be fair and upfront and you can't go wrong" Keep it real on the project, if you bring up a "problem" make sure you are talking about the "real" problem. If the "refresh rate" problem is more about you wanting to do the filtering design, be honest with the team.

5) "If everybody likes something no one will love it" Love comes with hate, like means it's watered down. When something is average it doesn't generate strong emotions, when something is great, it will also have its critics. But depending on the project, good and reliable might be exactly what is desired. Then again, the iPhone and iPad are not average, people love them and some do hate them.

6) "One veto and it's out" - Anyone on the team doesn't like something, it's dropped. What's left is everything great, but, of course lots of good ideas are rejected to keep the great. This again is how you rise above ordinary, and if your product is not required to be just good and reliable, you will need to reject some good ideas.

7) "Ya, probably not, though" Keep the language precise when you're discussing the project. This response by Ricky' to a question was very interesting, might lead you to wonder the next time he answers "Ya" is he really finished or if you wait long enough will he get to the point like "can't pay your salary this week".

This WILL get to an embedded design topic, but permit me a few paragraphs to get to the point.

If you have been paying attention to the news, our national government and those of nearly every state is in budget crisis. Here are just a few glimpses of the crisis:

"More than 40 states are projecting billions of dollars in budget shortfalls for fiscal 2012." 

"No formal budget was ever adopted for the current fiscal year, which began on Oct. 1, 2010." 

"Facing another fast-approaching deadline to avert a government shutdown" 

None of this should be a surprise, especially if you've lived through more than one recession. When the economy is good, individuals and governments as well become much freer with their(?) money. Then the economy turns, the revenue (incoming taxes) slows down and voila! budget crisis. You and I know what we have to do when we have a personal budget crisis: spend less, get more efficient or borrow money from someone willing to lend (much easier before 2008).

So which of these does government typically choose? First borrow more (not always possible for some states due to their constitutions that require a balanced budget - they can only spend out as much as they are taking in) and if/when required, spend less. But if you and I were to spend less like the government does, we would start by cutting back on milk and bread while maintaining a steady-stream on-demand pay movies on hi-def digital cable.Why?  Misplaced incentives.

"Human beings adjust their behavior based on the metrics by which they are evaluated." (a quote from HBR article by Dan Ariely: "You Are What You Measure." , NOTE, I have had trouble getting this site to load, but the link is correct). This means if you give someone an incentive, they will take it, and every measurement "scheme" you have is an incentive of some sort, though most not as you intended. Let's look at the well-known government budgeting practice called "Use it or Lose it". This technique encourages a program or department facing a budget surplus late in the fiscal 4th quarter (August) to spend every penny as fast as possible. 

Actually, there are many, many organizations who can help you get a piece of this action, like TargetGov.com with their helpful tips like: "End of the Fiscal Year, Big Government Spending" . The actual tagline for this site is "Helping you sell what government buys". Here is the intro to the referenced article: "We are now entering the fourth quarter of the federal fiscal year.  The federal government spends nearly 60 percent of the year’s budget at this time because of “use it or lose it” requirements." It goes on to provide tips to get "your share" of this spending free-for-all. I cannot vouch for that statistic personally, but if true is shocking. No wonder it's hard to make government better, if that is accurate. Of course, it must be, I found it on the internet :-) 

So when it comes to a budget crisis, and planners are facing a large shortfall, if you and your efficient department are showing year after year more results with less proportional spending, guess what happens when the money is short - the team that is NOT bursting their budget certainly doesn't need more when compared to a program that year after year can't seem to even get the same results with more money. Repeat this year after year and you can be sure to find over-budgeting (to be able to handle necessary cuts one day) and frivolous depletion of surpluses.

So how to fix the budget crisis (crises)? Incentives, but ones that reward efficiency, backed up by actions. It is obvious the "use it or lose it" budget incentives are NOT doing anything for efficiency.

OK, now that's settled, let's see how the same logic applies to designing embedded systems. Well, just like government budgets, you can easily incentivize the wrong behavior in your project. For instance, think what happens when you measure the quality of a software product simply by the number of defects reported against it. Under such a system, what would you expect a developer is to do when he/she finds a minor bug: report it or perhaps spend time trying to figure out how to ignore it with a clear conscience. "It might just be a corner case", or "perhaps no one else will find it" or "maybe the root cause is someone else's code". Besides, accurately logging a bug and detailing the steps to reproduce it takes real time to do right, and in the end it only adds a black mark to your product.

So if you have a "defect" crisis in your project, look at the incentives and the forecasted results, the "gaming the system" results like the example shown in this article on the "Defect Black Market" that developed in one project. But look also at the less obvious incentives, starting with the behaviors you find common that are not what you want (you may even find a "friendly" on the inside to provide clues).

Or like the government, just take the list of defects (or other measure) and just cut (or dictate a cut of) 33% off the top. Crisis fixed.

Jon Pearson
Methods and Madness, March 14, 2011
Happy 17th Birthday Linux (version 1.0.0 was released, with 176,250 lines of code on 14 March 1994. Go Linus and the open sourcers!)