Go Overboard on Features

I realize I'm treading on dangerous waters with the title of this weeks post, but I'm tired of hearing about "Architecture Astronauts" and "Creeping Featurism" in response to questions I ask developers about specific features. First and foremost, program architecture is something that you should think about before you start coding! The reality is that, even if you don't formalize this step, the act of coding is based on your current mental framework of the problem at hand and your previous experience with software.

I'm going to use one of my recent experiences as an analogy for the whole software development process. I wanted to give my family a home theater for Christmas last year, so I started buying equipment and planning how we would watch movies in our home. Now I probably wouldn't have gone so overboard with this room if my wife wasn't so good at decorating our home. With her (minimal) prodding, we decided that the room should have an "Art Deco" theme and that we should make it look like a vintage 1930's theater (though on a much smaller scale). Here's the story of how our theater came into being, what features it was expected to have and how all this relates to software.



Here's the "release plan" for the versions of the theater:

  • Version 1
    • Play movies from DVD
    • Play movies from VCR
    • Look like Art Deco movie theater
  • Version 2
    • Watch TV (this must be completed before the college football season starts as my wife is a huge fan
    • Provide TIVO functionality
    • Play classic video games
  • Version 3
    • Allow game console attachments
    • Add DDR capability (Check this out)
    • Add karaoke capability

As you can see, there are only a few features to be released in each version and the main point of the first version is to be able to watch movies. From an architectural perspective, the room was already in the house, so I knew what framework would be used for the theater. I had already purchased the projector, DVD player and surround sound system for Christmas (I love Best-Buy the day after Thanksgiving), so the electronics were also determined. What remained was deciding how to implement the Art Deco "Look and Feel" of the theater given the architectural constraints. Architecturally, this is analogous to the point in the project where you're told that your multi-user program must have a web interface; you don't really have a choice in the matter, but everything else you design will be constrained by this decision.

Once my wife designed the room, there were several additional architectural areas that needed to be addressed:

  • Electrical wiring
  • Electronics wiring
  • Controls
  • Look and Feel
  • Aesthetics and comfort

Each of these items had an impact on how the room was designed; The dimmable Art Deco sconces required new wiring in what had once been a bedroom. The electrical, projector and speaker wiring needed to be hidden (pulled through the wall) in order to allow the room to maintain a clean appearance. The electronics needed to be located in the room's closet (again for aestetic reasons). The tiered seating was required to allow all the "movie goers" to see the entire screen. The height of the risers had to be designed to fit the antique theater seats my wife found at Aurora Mills Architectural Salvage. The carpet and padding were selected to be comfortable enough to lay on but able to withstand soda and popcorns spills. The curtains had to block almost all light through the windows. The screen had to be painted with the right tone of silver and have the proper reflectivity. And while none of these "sub-features" was absolutely required, they combine together to provide a great experience to the users.

Ultimately, the user's impression of your product is the sum of all their experiences with your features! The bad news is that not all features are equally important to each user and a poorly done feature can have an exponentially negative effect, while a well done feature will often have a simple linear positive effect. Why is this? Two reasons; Users will remember the bad features because they impeded their work and users won't notice the truly brilliant features because they didn't have to think to use them. In fact, the best features probably don't even exist in the user's mind because they are so unobtrusive.

So here's my contention; Once you decide what features are to be included in a release, do them with excellence. Creeping Featurism is not about making spartan features ... the features that are important enough to add to the product should be usable. In addition, the architectural decisions made before and during the software design will have an impact on how the features are implemented and how easily the next versions of the product can be built. Unfortunately, it's very hard to measure what customer disatisfaction is costing you, so put your best into every feature (or leave it for the next release).

Here's a simple checklist that should be considered for each feature added to a product:

  • Is it intuitive? (can the user guess how the feature works without reading the manual?)
  • Is it comfortable? (This relates to the user's perception of the feature)
  • Does it fit within the architectural framework? (or did it require a major kludge to fit into the rest of the program?)
  • Is it consistent with the behavior of the existing features?
  • Does it look nice? (Again, from the perception of the user)
  • Does it accomplish what the user expects?
  • Does it accomplish what I've advertised?

My final point is a simple illustration ... let's apply the criteria above to a common user action. When I boot my Windows computer up, I get a dialog box that says "Press Ctrl-Alt-Delete to begin. Requiring this key combination at startup helps keep your computer secure." Here's my score for this "feature":

  • Is it intuitive? No, but I've been doing it for twenty years ... it would be amusing if Vista used that key combination for something else
  • Is is comfortable? No, it's awkward and even worse it you're doing it one-handed
  • Does it fit within the architectural framework? Yes, the key is always some system function
  • Is it consistent with the behavior of the existing features? No, it was used to reboot the computer in DOS and is also used to bring up the task manager
  • Does it look nice? N/A
  • Does it accomplish what the user expects? Yes, but have I been conditioned?
  • Does it accomplish what I've advertised? No, I don't see that pressing this key combination is any more secure than having the login dialog on the screen when the computer boots (and it wastes my time)

Was this feature ready for release? Are yours (or mine)?

Bonus thought: We had considered just putting a few sofas and a large screen TV in this room, but the cost was about the same. Going with the theater motif has an obvious "cool factor". Can you implement your features in such a way that your users feel a "cool factor"?

Features galore

I agree. As long as you have a unifying and simplifying theme, the more features, the better.

No, clarity

I think the most important thing is to be able to use the features I want and ignore the rest.

This is one of the places where software like Word does a good job. Most regular users know the standard key commands to bold, italicize, etc and the buttons representing the differing alignments, bulleted lists, etc.

As a result, they've set a defacto standard of sorts... even if they weren't the first to come up with it.

"So...you're saying have a

"So...you're saying have a few features only in each version, but make them rock!"

Exactly! I specifically chose the word "on" for the title instead of "with", because I wanted to differentiate between the idea of limiting feature creep or bloat and limiting the quality of the features that are implemented.

Judging from the comments, I may not have been clear enough in the article!