Are Features The Enemy?

blog
41

I think the Bill Gates quote about upgrading not being necessary just to fix bugs is quite humorous.

Considering that his development tools rarely get bug fixes. Remember VS2002 with the “Check for upgrades” menu choice that never ever found one single upgrade? I always wanted to see the source code around that one.

Every single bug we ran across was fixed in VS2003 (supposedly), too many to list them all, the source code reformatting when you switched between design view and source view annoying me the most.

So staying at the older version was never an option for us because the product was flat out unusable. Thanks Bill.

Feature bloat is a direct reflection of the way software is reviewed. Developers have merely reacted to the marketplace.

Feature lists are just ONE way to look at software, there are many metrics that reviewers ignore, so in the end dev’s just pile on the features. It’s similar to computer books; everyone just wants the biggest thickest book on the shelf for its perceived value.

Why don’t reviewers measure other metrics such as Space Occupied on Disk, Load Times and Interface Usability?

Why don’t they benchmark how long it takes a complete beginner to figure out how to complete major tasks? Or experienced users of the last version?

Change the review metrics and the software will change, I guarantee it.

42

It looks like Microsoft may have learned a lesson with the bloat of Vista. There building a scaled down version called MinWin that will only contain the essential pieces needed to run the OS. Only 25megs!

Story here…
http://www.crn.com/software/202404947

43

I like those feature charts, but only because I know how to use them: eliminate all the rows with features you don’t care about, then pick the one with the most bullet points (you might want to give different weights to more important features as well).

Some applications give you a checklist of plugins to choose from; I’d like to see a checklist of features. You’d get all the bugfixes and optimizations in each new version, but keep as many (i.e. as few) features as you want. Skinnable interfaces and Web 2.0 social features would be the first to leave my list…

44

I don’t think these last two blog entries could possibly have been more timely, as far as I’m concerned.

In working on NValidate, I was considering downloading the source code for a couple of open source projects so that I could review them to ensure that we provided lots of tests to handle the vast majority of parameter validations that developers perform.

While I may still do that, I’ll now think very hard about CONSTRAINING THE TEST SETS to avoid the inevitable implosion (an apt analogy, if ever I heard one, for anyone with any passing familiarity with the physics of mass and gravity and stellar demise).

Once again: Thanks, Jeff.

45

Great post, Jeff! Adding features while not fixing usability issues is one of my top peeves with poorly designed software. Fixing usability makes a lot more difference to how easy it is to actually DO something with the software, which is why I bought the %#$* program in the first place. I would way rather pay for enhanced usability than for features I don’t need.

The problem of reviews that obscure the information buyers need in order to make good buying decisions is not unique to software. Back in the '80s when I rode motorcycles, U.S. motorcycle magazines reviewed bikes, and buyers bought bikes, using a feature set similar to “Can do rotating 3D bullet points in color”:

  • Engine displacement
  • Horsepower
  • Acceleration 0 to 60 mph
  • Top speed

Engine displacement is irrelevant, since a bike can have a large-displacement, low-horsepower engine, or a small-displacement, high-hp engine. Need for horsepower depends on what you use the bike for most of the time. A bike (or car) with higher horsepower is significantly faster a little bit of the time, heavier and guzzling more gasoline all of the time. For most people, acceleration is less important than the FEEL of acceleration. A bike that accelerates fast but you don’t feel it is boring to ride (80s Honda Interceptor). A bike that accelerates slower but you feel a punch in the gut is more fun to ride. Top speed is relevant to some riders, but most people rarely use it. (Where can YOU ride 150 mph, and how often can you do it?)

Here are some things that make a REAL difference in keeping the bike from gathering dust in the back of the garage. Note that, unlike the list above, these are features that improve your experience of riding and owning the bike MOST OR ALL OF THE TIME:

  • Comfort. If the seat traps you in one position, and the bike buzzes so bad it puts your hands and feet to sleep, the bike won’t get ridden much.

  • Wide power band. This is another a comfort issue. A bike with a peaky power band (like a lot of the race bike clones of that era) requires constant gear changes. That’s okay if you are riding flat-out for 20 minutes, but a hassle on a long ride. If the bike’s not comfy on long rides, you won’t ride it as much.

  • Reliability. If it’s broke, it won’t get ridden. If parts are hard to get, it’ll stay broke longer. (Brands with a high degree of parts interchangeability between models, such as BMWs and Moto Guzzis, were a lot easier to get parts for than more popular Japanese brands that changed models every 0.003 seconds.)

  • Easy to work on. This is important even if you hire all the work done, because a bike that is easy to work on will be inexpensive to tune up and maintain. I’ve seen a lot of bikes sitting in garages because a tune-up cost so much.

  • Low center of gravity. The bike is easier to handle, more fun to ride, less likely to go down, and easier to right if it tips over.

IOW, usability, usability, usability. :wink:

I only ever saw one motorcycle model comparison that took real-world riding into account in this way. To simulate a flat rear tire, a magazine had each of 5 brands of touring bike stop by the side of the road and remove and replace the rear wheel. The Gold Wing was still sitting by the side of the road FIVE HOURS LATER when the BMW crossed into the next state. (The Gold Wing’s built-in panniers and loads of bodywork complicated access to the rear wheel. It’s high weight also complicated matters.) Just for fun I tested my sport-touring bike and removing the rear wheel took under 3 minutes, including getting the tools out from under the seat. I rode that bike every day year-round.

I LOVE the idea of applying this to software. How long does it take to do X? Pick some real-world job that users are likely to do. Have some users that are familiar with the old software, some that are familiar with a popular competing brand, and some that are newbies. Observe, and keep the stopwatch going.

Another important issue: useful, time-saving features that are so badly implemented that users don’t use them. Example: Word’s bad parody of style sheets are so poorly implemented that users avoid them. Result: most users don’t know how to use style sheets, and don’t understand their benefits. Which is too bad, because style sheets are one of the biggest time-savers ever invented.

Some of the best software I’ve ever used deliberately restricts the feature set to keep the program fast and functional. I like that.

46

digital all-you-can eat buffet

Haha, good comparison

I miss some oriental kind of thinking/living: Use only what you need.

Lions survive in Africa because they eat what they need, and not more. They could do as many human enterprises: Having great paws, they could endlessly hunt until there is not more left to hunt, and then optimize their hunting technics until there’s no more to hunt again, and then hunt other things or migrate. This way, there would be no lions today.

Some say (some not) that this is the reason why many things on the Earth are changing, such as climate, because we start to eat/consume more than we and Earth can digest.

May be software and its all-you-can-eat strategy feeds our sickly hunger because we ask for it: More features, please, dont’ mind if I use them or not, I’ll sleep better knowing they are there, somewhere in the box.

47

I’m not using Winamp anymore. I’m using musikCube. Light, has important feature and you run filter on your music, anyway… just go see the website http://www.musikcube.com/

48

Obviously, BugWord is the best. Because it can run an Atari.

49

Do you think there is a direct relationship between the number or lines of code and the adverse impact on the usability, sluggishness, downfall of a particular software package?

Are lines of code tantamount to number of features in your opinion?

for a typical business package that might do accounting, track sales, and manage stock, when do the limits of the size (in terms of number of lines of code) start to reach critical mass?

5,000?
10,000?
20,000?
more?

50

I’ve heard that Winamp 5.5 uses less RAM that the previous version, so don’t be afraid to download it (although the new skin sucks ass. still you can change it easily…). Nevertheless, I feel the same way with most programs. There is little difference between Office 2000 and Office XP, and later Office 2003. Even worse, they completely changed the interface in 2007 and now it’s more difficult to use than before. That’s why open-source is better: it takes much longer to spoil.

51

digital all-you-can eat buffet

I agree with Oscar - this is a good comparison.

To take the analogy further…

If I ordered a roast chicken ciabatta in a restaurant, it’s entirely likely that it would come with a full salad garnish. If I asked for no onions in my salad they would gladly serve my meal without. I’d still be charged the same, and they would still continue to serve the roast chicken ciabatta with the same salad garnish and onions because the majority of customers want the onions.

However, if most customers make the same request for no onions, then the restaurant would of course stop serving onions with the meal: it’s a waste of man hours not to. One has to assume that this is also true of paying vast numbers of developers to build certain features into a particular project.

If, on the other hand, I discovered that the tomatoes in my salad had grown green mould, I would not anticipate the waiter suggesting I pay to have the meal replaced. On the contrary I may even expect a refund or some other compensation for the inconvenience.

This ‘gimme features’ philosophy stems from our desire for conspicuous consumption: my software’s better than yours because it ticks more boxes.

On the other hand it’s also about fitness for purpose, and in no other market are we asked to pay in order that faulty goods be replaced.

52

This is hardly an issue limited to software. Bought a digital camera lately? They come with manuals as thick as your thumb to describe all the many features you’ll never use. For that matter, the notion that every generation of cameras has to Support! More! Pixels! is silly for most people, who mostly print (when they do at all) something like a 4x6 print. If they can even figure out how to download the pictures to their computer, he said snottily.

I don’t entirely agree that customers are asking for all these new features. Some, sure, but how many people demanded (for example) that (to pick one) Canon include a feature to create tinted photos automatically, or configurable shutter sounds, or a dozen other because-they’re-cool features? Those sound like Engineers Gone Wild to me. And, as noted, to be able to have more checkboxes in the reviews.

53

The problem with software, is that no ones going to buy a new version, if theres no incentive… Having less features then the competition just doesn’t work in the software model. The 37 signals philosophy is to do less then the competition, and it works, they give you what you need, and no more. But thats fine in the subscription based models.

54

As much as I agree that winamp has become bloated, at least they did it in a nice way. Almost everything is written as a plugin that can be turned off. The input and output codecs, file writers, CD burning, all the features of the file library, skin support. You can install a very basic install and get pretty close to a pre 3.0 winamp.

I really like this model and think it should be applied more often. Firefox could really use it. If I don’t like the tab implementation, sure I can get an addon to run on top and modify it, but why not replace it? If everything was setup as a plugin you could.

55

That’s why people smarter then us invented plugins. You can always release new plugins and let customer decide which features to buy/get. You can also remove a plugin you don’t need/want anymore.

56

Great blog.
Each one makes me think deep thoughts have gone into it.
99% interesting too.

Thanks.

57

The model is not doomed as long as computers get more powerful and memory and hard drives get cheaper and bigger.

The developer just needs to manage the features properly. Either install them on demand or install everything but load what you need as modules. The features you don’t need should not load into memory and should not show up in menus. They are out of your way. This way there’s no sign of bloat. Personally I don’t care if the whole app takes a lot of disk space. HD space is cheap but I do care to get more features as long as they don’t make the app less stable.

58

Using the MyWord example, if you find version 2.1 the most useful, don’t upgrade. That solves the problem completely (unless there is a specific bug preventing it from being usable).
The problem occurs when MyWord forces you to upgrade to the newer versions.

My favourite group of software/developers is http://www.suckless.org/wiki/
Why? They don’t prize themselves on huge numbers of features, rather they focus on compact, efficient and usable code, and making the current features work as they should.
The applications are limited to 10,000 lines - rather than adding a load more code to fix a problem, you fix the existing code.
http://www.suckless.org/wiki/about describes it better than I can…

59

Abdu writes: “The model is not doomed as long as computers get more powerful and memory and hard drives get cheaper and bigger.”

I disagree. HUMAN ATTENTION is not getting bigger. In any interface situation, attention is usually the most important bottleneck. It’s not that people CAN’T use feature X; it’s that knowing that feature X exists, finding it, learning how to use it properly, and REMEMBERING where to find it and how to use it, all require mental overhead. A person’s mental overhead is limited. I can’t just walk into CompUSA and upgrade my brain’s memory, attention, and comprehension units.

So the software designer’s job, in general, to minimize the mental overhead that the user requires to get the job done. The less mental overhead for the user, the more attention they have left to (a) use the program features they DO understand and remember, and (b) actually get some work done.

Mental overhead is reduced when a user can learn a feature, keyboard shortcut, etc. in one program, then apply it consistently in other programs.

Mental overhead is also reduced when the context supplies cues that help the user remember what to do. Limiting the cues to what’s appropriate in that context helps. It’s like the difference between walking into a kitchen and finding a kitchen (consistent context cues; you know what to do and what your options are), and walking into a kitchen and finding a kitchen, toilet, leather couch, porch swing, doorbell, and a patch of lawn. Yes, it’s got more features – BUT YOU HAVE TO THINK BEFORE YOU CAN USE THEM! That makes ALL the features harder to use.

I think Jeff is right: The more we can make “What will increase user productivity?” match “What will sell more software?”, the better off everyone will be.

60

I’m still using WinAmp 2.71 although it can’t playback all of today’s formats. But it starts lightning fast and has the smallest memory footprint than any other music player I’ve fumbled with.