Author: Andrew Stellman

The Kitchen of the Future

~ Andrew Stellman ~ Leave a comment

A clear need for a better kitchen

What is it with futuristic kitchens? I swear I’ve seen the same TV segment about the “kitchen of the future” repeated on different channels with different people at least twice a year for the last decade or so.

This wired article seems to have a good description of the generic kitchen of the future:

Kitchen of the future
General Electric
What if your appliances were so smart they took the drudgery out of meal preparation? “Your kitchen can basically be your sous chef,” says Marc Hottenroth, an industrial designer who helped create GE’s concept kitchen. Call home from work and your pantry and fridge – outfitted with RFID readers – will tell you what’s stocked, suggest meal options, and list the ingredients you’ll need to pick up at the grocer. (They’ll also remind you to buy milk when you’re almost out.) Craving a quiche? GE’s kitchen will guide you through assembling one and heat the oven to the optimal temperature. If, say, elderly Aunt Rosa is visiting from Italy and wants to whip up some gnocchi instead, the appliances can display text in larger type … and in Italian. What’s more, GE’s setup redistributes energy (such as using excess oven heat to warm dishwater) to lower power bills. Rather not cook tonight? The kitchen can find a number for pizza delivery.

There you go! It’s got everything. It gives you recipes, tells you what’s in your fridge, and lets you look up phone numbers. All that, and it will remind you to buy milk.

Sounds great! So why does the kitchen of the future rub me the wrong way? And, more importantly, what lessons about building better software can we learn from the kitchen of the future?

Let’s put aside for a moment the fact that it’s pretty unlikely that your elderly Italian aunt Rosa doesn’t already how to make gnocchi. There’s one thing that’s true about every engineered product, whether it’s a stove, software or a slide rule: it’s built to meet someone’s needs. But there’s another thing that’s almost always true: some needs aren’t obvious. And it may just turn out that you’re building a kitchen that doesn’t actually meet real needs that people have.

Here’s an example. A hat seems like a pretty simple product that meets a straightforward need, right? It keeps the sun off your head. But wait a minute… plenty of people wear baseball caps inside, where there’s no sun to protect you from. And they’re not playing baseball. So hats fill another need — they help the wearer feel fashionable. And there are other needs, too. A baseball cap has a visor that’s placed in a way that shields your eyes from the sun, but it also advertises a sports team, and, when adorned with the proper Greek letters and bent in exactly the right way, makes frat boys look cool to other frat boys. Those are all important needs.

What about a toy program that you just threw together in your spare time because you were bored? Does that fill a need? Sure! You needed to kill some time, and it served that need perfectly.

So what does all this have to do with the kitchen of the future?

The perfect kitchen GUI?

Take a minute and have a look at this excerpt from a CNN transcript of a segment about one particular kitchen of the future:

TIM WOODS, VICE PRESIDENT, INTERNET HOME ALLIANCE: This is kind of a nerve center for the entire kitchen. In fact, it’s the nerve center for the home. This is the HP TouchSmart PC. And it’s kind of social computing, right, at its best.

But the idea here is, you put everything in one place at a touch point. There’s a middleware program on this from a company called Exceptional Innovation. And what that did is, it brought all of these elements like lighting and shade control and music, and put them all into one interface. Now, mom does about 80 percent of the input on any family calendar, but she wants the ability for dad to go in there, the kids to go in there, leave notes – do all of these things that really become tools for the family.

Now, I don’t want to knock HP and Exceptional Innovation. I’m sure they worked hard on their software, and I certainly know what it’s like having a product to sell. And they’re following the siren call of the Kitchen of the Future that plenty of people have followed before, and I can’ blame them for that.

But really? Controlling the lights and keeping a family calendar — is a computer really the best way to do that? Most families have a dry-erase board or calendar stuck to the fridge. It meets their planning needs really well. It’s much more Agile. (And, interestingly, it never crashes.) Think about it from a software development perspective: do you want to go through a whole bunch of screens in a touch-screen GUI to get to your calendar? Or do you just want to go scrawl a note with a marker? Which of those seems “heavyweight”? Which seems more agile?

The same goes for controlling the lights and the entertainment center. Most kitchens have a small handful of lights. I’ve yet to find a software interface that works better than a light switch or a dimmer on the wall. Plus, you can find a light switch in the dark when you’re half-asleep and looking for a midnight snack. I’d be surprised if that’s a need that most lighting control software developers realistically considered.

Which brings me to buying milk. Just about every Kitchen of the Future I’ve seen in the past ten years makes a point of being able to tell you that you’re out of milk. (On the video, the computer in the CNN segment showed an image of a Post-It note displaying a hand-written note that read, “Buy milk!” I have the feeling that showing a picture of a Post-It note seems, from a UI perspective, to be an admission of defeat.) Is it a real need? Yes, with the exception of or vegan friends, we do all need to buy milk.

But is it really so hard to figure out when you’re low on milk?And if it is, can we realistically expect the kitchen to know when we’re low on milk? Will we always need to put the milk on a special Lose Weight Exercise sensor? Will I get a false alert when little Kaitlynne or Brandyn puts the milk back on the wrong spot in the fridge? Does it know when my milk’s gone bad, or only if it’s low? It all seems far more complex and error-prone than just having a stack of Post-Its and a marker next to the fridge. The simplest and most convenient solution to the problem is still scrawling “buy milk” on a Post-It and sticking it somewhere obvious.

And that’s my point. When you get down to it, the Kitchen of the Future is available to us today at a reasonable price. Why don’t we all have one? Because it doesn’t meet a need. It’s an Lose Weight Exercise in gold-plating. It’s a solution in search of a problem. And I get it. I’m a programmer at heart, and I love new applications of cool technology significantly more than the next guy. But we won’t find buyers for our products if they don’t fill a need.

And that’s the software lesson to learn here. Make sure your software always meets someone’s needs before you start building it. Because the last thing you want is to put your Kitchen of the Future out there, only to discover that the world’s just not ready for it yet.

Late projects, man-months and the software crisis

~ Andrew Stellman ~ 1 Comment

I recently got a question recently asking about Fred Brooks’ famous quote: “Adding manpower to a late software project makes it later.” The person asking the question took it literally, and was asking about whether this meant that there’s no way any schedule estimation technique could indicate that adding manpower could shorten delivery time.

Fred Brooks wasn’t really talking about schedule estimation techniques, or writing hard-and-fast rules. He was trying to help software engineers break some very bad habits. And trying to fix a failing project by throwing bodies at it is one of the worst habits software engineers have. See, as it turns out, some tasks take however long they’re going to take, and throwing bodies at the problem won’t change that. Or, as Brooks wrote, “The bearing of a child takes nine months, no matter how many women are assigned.”

Business Plan

I think the best way to understand that Brooks quote was to understand why he first wrote “The Mythical Man-Month” back in 1975. At the time there was something called the software crisis. The field of software engineering, still young at the time, had run in to a serious problem: people were having a whole lot of trouble writing software on time and under budget.

By the time the software crisis was in full effect, the engineering world had already matured a great deal. The great civil engineering projects of the early 20th century taught us how to manage enormous projects effectively. (Hoover Dam was finished two years ahead of schedule! And Henry Gantt invented of everybody’s favorite scheduling tool around 1910.) And by the mid-1970s, the world of computers had matured to the point where most large corporations had computer programming teams and IBM “big iron” timesharing mainframes. It seemed like the tools were there, and the people had the skills to use them.

So why were all of our software projects so late?

Personally, I blame the person who coined the term “software”. The thinking, I believe, went like this: “Hardware is really expensive, and basically impossible to change. But luckily, we’ve got these programs that we can constantly tweak to suit our needs! That’s the opposite of hardware, which can’t be changed.”

By the time the mid-1990s came around, the field of software project management had matured to the point where we knew that change was the biggest factor in late software projects. Changing needs and requirements meant pulling apart the underpinnings of our code and caused us to have to do expensive (and often ineffective rework). Changing technology kept giving programmers “silver bullets” that they thought would make this next project run a whole lot more smoothly than the last one. And the (perceived) ability to change the software architecture and design in the middle of the project caused a lot of teams to fail to plan their projects well (or at all!).

The worst part of it was that it seemed like the software crisis never ended — there were still an enormous number of projects that were still coming in very late and over budget, or failing to complete at all. But at least by that point we knew the root cause of the problem and had tools to help us fix it. In fact, we were learning that adapting to change and getting those changes under control was an important part of effective software projects.

So how did we know that those things were causing the crisis in the first place, and that fixing those problems would get our software out the door on time and within budget? We can thank Fred Brooks for that. “The Mythical Man-Month” was, as far as I know, the most important software engineering book of its time. It laid out the real problems that caused software projects to run into trouble, and showed us a lot of very useful ideas about planning our software projects, structuring our teams, estimating the work, communicating with each other and our stakeholders, and writing our documentation. And a lot of what he wrote still resonates very well with modern software projects. (A lot of the tools and techniques that Jennifer Greene and I wrote about in Applied Software Project Management were designed specifically to address those root causes of software project problems.)

And that gets back to Brooks’ quote about adding manpower to a late project. When Brooks talked about a late software project, he was talking about a project that had constantly shifting requirements and needs, poor planning, and communications problems both among the team members and between the team and the stakeholders. In a situation like that, many project managers will panic and just try to throw bodies at the situation. (I’ve seen this many, many times — and so have almost all software engineering professionals.) But those extra people will just cause the bad project plan to become even more inaccurate, and they will compound the already serious communications problems. That, in turn, will cause the team to spend extra effort dealing with those problems. And that extra effort will often be larger than the man-hours that the newly added team member will add to the team.

That’s why Brooks called his book “The Mythical Man-Month”. If you need to get your two-person project done in six months, you can’t just add another person on and magically get it done in four months. Adding a person to a project for a month doesn’t automatically reduce the total effort by one man-month. The effort that one person can contribute to a project varies enormously based on the project circumstances. His “adding manpower” is saying that if the project is already late, then adding an extra person can actually subtract man-months from the project.

PMP Study Tip: Write Your Own Questions

~ Andrew Stellman ~ Leave a comment

The PMP exam is all about questions. That’s a little obvious, I know. But think about it for a minute: you’ve got 4 hours to answer 200 questions. It’s a nerve-wracking situation if you’re not in the habit of taking exams — and few professionals are. That’s why one of the best ways that you can prepare for the PMP exam is to write your own questions.

But don’t you need to be an expert to write your own questions? Definitely not! It turns out that there are only a few ways that make sense for presenting the kind of information you’ll see on the PMP exam. Getting a good feel for them will really help you get more comfortable with the material, and it will help you separate the ideas being tested on from the wording of the question. Most of all, it will help you think more about the material, and come up with practical situations on your own for applying it. And that’s a very effective way to study.

It’s hard to know where to start, though. It turns out that writing good questions takes practice. That’s why Jenny and I added the “Question Clinic” Lose Weight Exercises to Head First PMP. It turns out that a lot of the questions on the exam fall into just a few categories. There are different strategies for each kind of question, so recognizing the question type can help you get more answers right. But even better, being familiar with how questions work can really help keep you calm on the exam, because you’re faced with a lot fewer surprises. Pretty neat, right?

Bring Your Own Questions

Our friends at O’Reilly just put up a great tool on the Head First Labs site. It’s a fill-in form that helps you build your own questions, with templates from all of the Question Clinic Lose Weight Exercises in the book that show you the different kinds of questions. Even if you aren’t using Head First PMP to study for the exam — obviously, we hope you do! — you can still use this to help get a handle on writing your own questions. (You can also feel free to use the Head First PMP forums to ask questions and get study tips.)

And don’t forget: any time you run into a fact that you don’t know, or if you get a question wrong on a practice exam, write your own question for it. It’s a great way to get the information to stick to your brain!