Features: less is more

Imagine this:  You are in the market for a new blender.  All you're going to do with it is to make smoothies and milkshakes.  If it grinds ice and the parts are dishwasher safe, that will do.

You walk into your favorite small appliance store and see a row of blenders.  None of the prices are shown.  Almost all of the blender boxes say that they will make smoothies and milkshakes.  Two of them say they're dishwasher safe.  One of those two blenders can also shred metal, is easy to take apart, has measuring markers on the side, and comes with a set of six exchangeable lids, identical except that they're white, black, green, brown, red, and pink.

But again, it's hard to tell the price.  The cash register is downstairs at the far end of the store, and there are no price checking stations to be found anywhere.

Which would you choose?  Most people would choose the simpler blender.  Why?  Fit for the customer's needs, and "I don't need all of those extra things," and "It will cost me more."

In product management, whether it's software, blenders, or even a resume the concept is the same -- less is more.  Your product needs to fit the customer's needs, but not beyond that.  More is not necessarily better.  In fact, the company could be earning a much smaller margin on each blender because of the cost of those additional features and the requirement to keep the price under a certain level.

By the way, I checked the web site - the simple-looking blender actually has many of the features of the fancy one yet still earned the sale.  ...but that's more of an outbound marketing issue, isn't it?

Privacy in social media

There's an old story of two hikers who come across a hungry-looking bear in their path. The first hiker starts running for his life. The second hiker stops, sits down on a rock, takes off his heavy hiking boots off, reaches into his backpack and pulls out a pair of running shoes.

The first hiker yells back at him, "What the heck are you doing? You know you can't outrun a bear!" To which the second hiker matter-of-factly responds, "I don't have to outrun the bear, I just have to outrun you."

More on that story in a moment.

Whether it's Twitter geolocated tweets, photos that include GPS metadata, or your Facebook profile, you have the option of sharing with the world where you are.  If you share pictures of your kids that include GPS coordinates and most of them are clearly taken at home, you've just advertised where that child lives.  ...and as you probably already know, there are bad, crazy people out there who are looking for you and your kids for any number of reasons.

Note to self, recheck pictures on Facebook to see if they contain GPS coordinates.

What you may not realize is that you are one entry in a phone book.  I'm not saying it's okay to share with the world that you're about to be a mother or father and all baby gifts can reach you at P. Sherman, 42 Wallaby Way, Sydney, Australia, but adding to your Twitter profile that you live in Sydney is probably fine because Sydney is, after all, a pretty big place.  So is New York, San Francisco, San Jose, etc.  If you had a lot of enemies, could they still find you?  Yeah, Zabasearch is one way to do it.  For most of us, though, it's a lot like the story of the bear above.  You're aiming to not be the easiest target. 

Also remember that most people are too busy thinking about themselves to obsess about you, so unless you come across someone particularly crazy and vengeful or have decided to plant $100 bills in your front yard and word is getting around, there's no value in someone travelling miles to seek you out. 

Tips:

• For most people living in large cities, it's okay to make your city of residence public.  Like opting in to newsletters from your favorite stores, sometimes a little bit of information out there can make good things happen (e.g. an old friend decides to get back in touch when in the area). 
• Make private matters known only to people you trust. 
• Most crime happens among people who know each other, and chances are you know which of your friends and family you can trust. 
• Employers may not be "out to get you" but if you're looking to get a job or keep a job, you probably don't want them to read about certain things you post publicly that might reflect badly on them.
• Facebook and Twitter are by default not private, so even if you decide to keep that the way it is, just remember who your audience is.  More than just your Twitter followers have probably read your post about Charlie Sheen, for example, since it's very easy to search for tweets without ever logging in.
• Your video of the kids posted on Youtube is probably fine, so long as you keep the above points in mind. 

Yeah, but we can build things that barely stand up!

In college I remember taking a class at UC Davis in which the professor started a lecture one day saying that, "anyone can build a house.  Throw enough materials at it, and it will be a suitable home."

Then, with a smile on his face he added, "but engineers can build a house that barely stands up."  He said it as if he was proclaiming the cure for world hunger.  Someone in the class murmured, "We can probably do better than that..."

That comment, plus a number of quizzacle looks on students' faces prompted him to explain, "We know how to build a strong house with the minimum amount of materials.  Anyone can build a house, but usually it will contain a lot of wasted resources or won't be as strong."

That class was a general Engineering course.  How does this apply to software engineering?  Thinking back further, I remember reading something from Steve Gibson, whom created SpinRite and other apps, claiming that the efficiency of software had become a lost art, and that a program written to accomplish a fairly simple task now consumes a large amount of disk space, RAM, and processing power when it could have been accomplished within a few hundred kilobytes and under 100 megahertz. 

Well okay, that's not an exact quote, what he was getting at is that we've thrown a lot of resources at a problem when the solution could be quite simple.  Many programs written in Java are built to be interpreted and compiled on-the-fly, increasing application portability at the expense of size and processing power.  Software contains interfaces and procedures for crunching data from other programs that the user may never use, and that would only be activated with the right complimenting technology.  In the mean time, it consumes disk space and memory.  Visual software development tools make it easy to develop a computer program, though the computer's interpretation of what was intended is sometimes ambiguous and opens security holes. 

Entire libraries now have to be shipped with a product even when a few of those functions are used by the program.  That's probably not such a big deal -- it's akin to leaving branches on the tree logs used to build your log cabin.  A little unsightly, but it's not doing any harm, and there's nothing wrong with the part of the tree that's being used, right?  Wrong - if some of the unused libraries are insecure and leverage the parts of the library in use, it would be like putting termites into those branches.  Eventually they could reach the core of the house. 

This is getting abstract, so let's come back to a real life example of software engineering sloppiness:  A few years ago, Magellan sent out an update for its GPS devices that required the user to enter an activation code based on the serial number.  The installer interpreted the serial number string as a number.  The activation code generator interpreted the serial number as a text field.  That wouldn't matter except that since the integer variables didn't bother to store the number of leading 0's in the serial number field, the activation code came out differently depending on whether the leading 0's were read or not. 

Here's a security example:  Stuxnet used a number of small holes and hooks to get where it needed to go.  (http://www.isssource.com/tag/how-stuxnet-spread/) That included USB drives, print spooler services, autorun.inf, Siemens project files, and finally programmable logic controllers.

Put this way, it looks like as we make it easier to build software, we're all following the "anyone can do it" methodology.  Software engineering becomes cheap.  So going back to the beginning of this article, where's the engineering element of building it right?  How do we build strong software with minimal resources?  Should we all go back to building software with assembly?