Subtitle: Another digression about talking with those silly customers

I had a discussion with a good friend the other day - we’d spent years fire-fighting embedded systems gone wrong. During many all-nighters and several 110-hour weeks, our deepening ire became sharply focused on the idiocy of using zillion-line industry standards as product requirements.

On that project, there was no “customer need” or requirements document. I’d never met a customer. That was 12 years ago. It hasn’t changed much, he admitted. Now, as it was then, buggy products are still late.

Then I was approached by a university to redo their senior design program. Cooool - I got to indoctrinate brand-new engineers to the entire industry-standard process: starting with customer needs and requirements. “Back away from the keyboard,” I told them. “TALK to the customer.” And you know what? They got it!

To my delight, my best teams delivered beyond the customers’ expectations, and one won a national design award for their work. (Their story is below)

If graduating engineers can do it, why can’t we?

Reminiscing about the Future

Lisa, why do you care about all this? Requirements are boring. Please dear girl, go back and muse about something fun like your experience debugging with hacksaws.

Yeah, those stories are amusing, truly. Painful then, but fun now. But did those 110-hour weeks make the subsequent telling of all that pain/fun worthwhile?

(Let’s all pause and relate.)

This could be a rant, but it’s more a deep cycle of sadness and frustration. Like you, I’ve suffered through horrid requirements disasters. Unless I was able to force and control large chunks of the process myself, the product was always late or canceled. Hey - I’m not self-aggrandizing - it’s just been enough of MY anecdotal experience to make me stop and think.

Less work. More success. Hmmm - could be something to this.

I’ve become a believer that thinking the customer has something useful to contribute - not just initially but throughout the process - might be useful. And that perhaps we ought to ask them (and listen) more than once. Customers are not perfect, and often thwart our efforts intentionally or not. I’ve ranted on this elsewhere, so my thoughts here are more musings.

Yeah yeah yeah. We’ve heard it all before. Sigh.

Back in the Not-So-Olden Olden Days

When I coded my first cell phone, my colleague and I breathed IS-95, the CDMA precursor to today’s CDMA1X. (This is the technology allows you to text message and download all those really cool videos on Verizon networks.) Like all typical industry standards, it is approximately a zillion pages long. Between Bill and I, we knew the entire standard. Could quote chapter and verse.

Because we had to. It was our requirements document.

My first day at work, my new boss walked me to the back wall of the building - a huge cubical farm with at least double or triple height ceilings. I craned my neck up to see a huge banner. About 9 feet tall and perhaps 70 feet long. Pinned at 3 foot intervals from start to finish.

It was the Gantt chart from hell

I accompanied him along the wall to the “80% theoretically-complete point” while he shared that the phone was to ship in 6 months. We were nowhere close to field testing. Then he pointed to a thin blue line I could hardly make out in the distance - “This is your first assignment,” he revealed. Then proceeded to inform me I was already late.

Welcome to the world of complex, multi-year commercial products. (And the idea that a project plan is ever static enough to be printed out, let alone attached to an entire wall)

“Please Hold On to the Bar, the Ride is About to Begin”

A few hours later Bill wandered into my office. Sat down. Got comfortable, as I tried to be the Perfect New Employee. Then without preamble, he began talking. For about 3 hours. An introduction to Code Division Multiple Access (CDMA), our particular cell phone deliverable, his and my place in the Master Plan, an informal assessment of my programming and design skills. Clearly, he was forming an overall gut feeling of my ability to hit the ground (I mean, be shot from a cannon straight into the ground) and survive.

Apparently I passed the first (several?) tests. So he took me to the lab. By way of the coffee machine.

(The company provided free coffee. Oh I get it, you nod.)

Ahhhh, yeah.

He and I fast became fire-fighting colleagues; partners in crime. Those “two engineers in the back of the lab who you should bother only in dire emergencies because they are the only ones who sort-of understand the software mess that our company inherited from a joint venture gone wrong.

During that insanity (which lasted 2 years) I became engaged and somehow planned a wedding. (Did I mention 110 hour weeks?) My boss asked if I would postpone my honeymoon. He chuckled to imply it might be a joke, but I think he was serious. Feeling me out. But with the combined support of my team behind me (and wonderful Brian who sat outside the meeting room so as not to infect me with his cold), I declined.

Can you believe what this pressure does to our reality? What seems rational?

What is a Requirements Document?

Hell, when I landed my first engineering position, I had no idea. I thought it was some marketing thing. Like when they show up in your boss’s cube and a heated discussion ensues, and then your boss shows up on YOUR cube and piles more stuff on your plate.

Or sometimes a guy from marketing would show up and ask, “How hard would it be to add <insert completely unanticipated feature here> into the product?” (I must share, though, that they did ask nicely.)

Later in my technical life, I was exposed to the formality of a process version tracking system. Hmmm. It tracked bugs and bug fixes. Useful. And since I still didn’t know what a requirement was, I didn’t comprehend tracking could be for anything else.

But I digress.

Bottom line I guess (no surprise) is that our phone was late. We hobbled (and prayed) through an international trade show. As the technical expert in-tow, I babysat the delicate little things, downloading new software every night at 2400 baud. At 2 am. Cheapest international calling rates.

I didn’t sleep much. But somehow we got through the trade show - the first launch of CDMA phones (you know, those Verizon phones) ever.

On our return, we cleaned up the lingering bugs as best we could. Spectacularly, we received approval and ship acceptance!!! My own “no dropped calls” algorithms had won over two service providers!

And the day we delivered phones to our first customer (Oh YES!!!), the company laid us all off.

/Rant (Wait, you said this wasn’t a rant)

Yeah yeah. I know. But lest you newer engineers think, oh well, Lisa and those other fossils who comment on this blog are just out of touch with how things are now… and that it’s just not like that anymore

It is no different now. Accept. Please. You will be able to make it to your kid’s soccer game. And that’s important.

How does that saying go?

No one ever went to the grave thinking, ‘I should have spent more time at the office.’

Instead, I like this other quote:

Life’s journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting ‘Holy shit…what a ride!’

Oh sorry, another digression. But, seriously, humor is a gentle way to slap us in the face.

While I don’t sit in the lab coding anymore, I’m still an excellent fire-fighter and technical leader. Today I manage projects. I’m a little behind in the newest tools - I don’t know C# or Ruby-on-Rails. But I can still guide a problem-solving effort regardless of the technology.

Because see, the tactical methods of today may be different than 10 years ago, but the strategy and the needs are the same.

Don’t confuse the two.

The strategic planning (including a business case, customer needs, marketing requirements, etc.) is supposed to happen first. And then tactical - specs, concepts and design analysis, design specs, etc. And it’s probably a good idea that the folks doing the tactical work have a clue what the folks who did the strategic work actually decided.

Just the experience of a product manager who rose through the ranks…

Forcing more debugging in the field

I may have had to lug an entire desktop computer and CRT monitor to Asia to download new software in a mad attempt to make it through this trade show… but I suspect all my past and your current pressures as the same. Many of the causes are the same.

(And you didn’t have your computer held up in Alaskan customs for 3 weeks. And finally receive a non-functional unit and cracked CRT. Heh heh - sorry, fossil-talk.)

Same problems today, different methods of torture. Cool stories either way - so let’s go have the proverbial beer.

Avoiding endgame fire-fighting disasters

(Oh boy avoid broken record language…) Really. Truly. Upfront work requires use case analysis. And perhaps you disagree, but in my experience, this is most effectively done as a collaborative effort between marketing and engineering. (This is hard.) And also by yourself, you should go into a private room if you need to, and pretend you are the customer. Pretend to do what they do.

I have a huge white board for this (and for other mental meanderings, useful and not). You should demand one, a really big one, as a condition of employment. ;-)

But how many of us actually do this upfront work? How many of you actually do COMPREHENSIVE USE CASE ANALYSIS? (Sorry, don’t mean to yell.)

Use cases and pretending to be the customer isn’t some BS exercise dreamed up by someone attempting to sell software in order for you to implement it. (Well, maybe sometimes…) But it behooves us to dream up and actually walk through, step-by-step, how a customer might use a product. And no offense to customers, but we need to recognize that customers come from all walks of life.

Oh, the customer is not who you think they are (You hear maniacal laughter in the distance)

You cannot assume your customer actually cares about your product. Sure, folks figure out the function and any quirks of a cool product like the iPhone. But if the printer jams, how long do you try to fix it while getting toner all over your hands before blowing it off for the next person to deal with?

We have lots of customers:

  1. Interested customers (”I really want to figure this thing out”).
  2. Customers who try hard to use your product “as intended.” (”Why the heck won’t this modem connect to the internet? I’ve tried rebooting everything.”)
  3. Customers who just want it to work right, dammit, and will blame you if it doesn’t work according to their impression of “as intended.” (See my rant on remote controls.)
  4. Customers who use problems or misconceptions about your product as an excuse for avoiding work. (”Sorry, couldn’t get the report out - the network was down.”)
  5. Customers who will actually sabotage your product in order to take down an assembly line so they don’t have to do any more work. (”The machine doesn’t put the sealing tape where it’s supposed to - it’s broken. (Ah, well, since you “adjusted” the laser position sensors while the plant manager’s back was turned…”) And then pissed-off plant managers call you and complain that your machine isn’t working right. Again.)
  6. And lots of other situations you can’t imagine. But you should try to.

Think outside the box. Pretend you are using the product in a hurry because your boss is coming. Because it’s Friday night and you friends are getting together for drinks. And (heh heh) the last category I listed above is a very real and frustrating one. These are clearly UNANTICIPATED CUSTOMER NEEDS!I could tell you stories… ‘Nother post.

My Wonderful Award-Winning Design Team!

In another post, I’m gonna tell you a couple good stories about good and bad customers. But I want to share the story of my pride-and-joy team of new engineers who blew the customer away. By talking to them.

I designed and taught a “real world” senior engineering design program based on industry design processes. I would like to share (and give credit) to a team of excellent engineering students who threw themselves whole-heartedly into the unfamiliar “Real World” experience of product design based on customer needs.

The team was challenged to develop a method to rapidly change the camber (angle) of the wheels on a wheelchair for research projects on shoulder mechanics. Customers included biomedical engineer Andy Kwarciak and SueAnn Sisto of the Human Performance Movement Analysis Lab at Kessler Foundation Research Center.

Let me quote from their customer, a year after delivery:

As a lab were we extremely pleased with the final product. I commend the students for coming up with a range of good ideas and for selecting one of the tougher solutions to implement. It demonstrated their determination and willingness to exceed.

The keys to the project success were 1) good communication, 2) good ideas, and 3) well-directed effort. The students focused their efforts on coming up with a great solution to a manageable project, instead of over reaching. I think everyone wants to design the next greatest thing, but sometimes its best to take design one small project at a time. I don’t mean to undersell the project or the students. They were both great. The key for me was that the project was well conceived, it was highly appropriate, and the students were very receptive and eager.

Let me repost here a news article at New Jersey Institute of Technology (Newark NJ) I made last year to publicize their achievements.

Senior Capstone Design Project to Assist Spinal Cord Injury Researchers Selected in Top 5 Students Designs at National Conference

The students’ work was selected for presentation at the 30th Annual RESNA conference (Rehabilitation Engineering and Assistive Technology Society of North America) in Pheonix, AZ, and the team won placement in the Top 5 student designs in the annual Student Design Competition! Their work was also featured at the NCE Salute night in April.

Samir Shah, Dan Ramirez, Advisor Dr Lisa Simone, Jay Kothari, and Amit Kaushal at NJIT's NCE Salute, 2007

Post Script 2 - Bill Biessman

Bill is an excellent embedded engineer, debugger, and resource. I recommend him very highly both as a professional colleague and personal friend.