Keeping Up with the Technological Joneses

If you have a competition to your software that, as much as you hate to admit it, is selling better than your software, you might suspect that you need to add more features to your product to keep up. But it might not be the sheer number of features that’s holding back your product! Perhaps the other product is more solidly built or is easier to use. (In other words, the other product might be more useable.) But even if you don’t have a competitor that sells better, you still might feel like the only way to stay ahead is to add as many features as possible. And that’s a topic I discuss in the following sections.

Running Rampant: Managing Feature Creep

Remember back to a year before Windows 95 came out? People were constantly getting into arguments that bordered on the religious over whether Windows 95 or the new IBM OS/2 was better.

Well, news flash: In terms of technology and features, OS/2 pretty much won without a question. But look who the survivor was. It turns out the feature comparison didn’t determine the winner. It was all about the marketing. Microsoft has always been a serious marketing machine. I’ve had very little experience with OS/2, so I wouldn’t be honest if I tried to compare the usability of Windows 95 to OS/2. However, I would daresay that Microsoft did spend a good amount of time on the usability of Windows 95. And they didn’t worry about out-featuring the competition.

Too many companies have this notion that they need to keep adding feature after feature to their products. I don’t need to explain to you that going overboard on features will simply delay the release of your product. But going overboard on the features can also impact the usability of your product.

The more features you have, the more menu items you’ll probably have, the more windows and controls you might have, and the more confusing your product may be. Of course, I’m not trying to say you shouldn’t have a feature-rich product. What I am saying is that if you want a lot of features, make sure you do the following:

• Create features that are well defined.

• Make sure the features are clear to the user.

• Make sure the features you include are actually needed by the user.

• Create a product that doesn’t overwhelm the user with all its features.

• Don’t continue adding features once the coding stages of development begin.

• Draw a line during the various planning stages at which point you agree that the feature set is complete and you won’t be defining new features.

If you continue to think up new features after the project begins, or if you just keep defining more and more features and delay the actual coding of the project, you are falling victim to feature bloat. The way to avoid feature bloat is to recognize that having more and more features does not necessarily make a better product. Instead, pick your set of features, stick to them, and make those features as highly useable as possible by following the guidelines throughout this book.

Then, while the competition is busy going overboard on their features and none of them work well, you’ll have a clear set of features that are powerful and easy to use. Add to that the wizardry of your marketing department (something I’m not qualified to teach you about!), and your product will easily outdo the competition.

But just how do you draw a line on your features? How do you know when to stop? If you take time to test the usability of your designs, you will get a clear idea of which features are vital to the product, which features are nice to have, which features are added fluff, and which features are totally unnecessary.

However:

RULE

The development group won’t be the ones choosing the features. By nature, programmers aren’t necessarily involved with the end users and may not know what the end users need and want.

Instead, the marketing people and the sales engineers and other people will be gathering information on what should and should not go into the product. Of course, the engineers can also have a say by suggesting some new features, as can the testers and anybody else. But after you have a solid set of features, describe them in detail in a feature document, and then have the head of marketing sign off on the document. This will indicate that the marketing people agreed to the features.

Of course, after the signing off, people are going to still be suggesting features. What do you do with these suggestions? You save them for the next release. You have to. Otherwise, you’ll start down the feature creep path.

Similar to feature creep is a problem that Fred Brooks describes in his book The Mythical Man-Month. This problem is called second-system effect, and it refers to what happens when you have a decent version 1.0 product, and then you get excited and decide to create for version 2.0 the absolutely most amazing, stunning, awesome product on the planet. But instead you end up with something that’s so bloated with needless bells and whistles that the product nearly implodes from its own weight like a black hole. But more concretely, such feature overload usually simply results in software that is too big and bulky and difficult to use.

The way to manage the second-system effect is by not getting carried away with version 2.0. Become extremely conscientious of the second-system effect. Don’t just pile on all the features you didn’t have time to add in version 1.0.

Here’s an example: The team is working on version 1.0, and in the middle of a meeting, somebody suggests a new feature. You, as the manager, do the right thing by saying, “Too late, we’ve already frozen the features on version 1.0.” But then, you add, “Let’s get that in for version 2.0.” You make a note of it, and the decision is made.

Did you go through the usual process of adding a feature? No. Instead of interviewing end users and working with the marketing department, you slipped in a new feature much like a rider secretly snuck into a bill before Congress: It’s perfectly legal but not always ethical. And in your case, ethics aside, it’s rarely beneficial.

RULE

Follow the correct path for adding features, and don’t just plan on version 2.0 being the ultimate killer app.

Running Rampant 2.0: Avoiding the Latest Whiz-Bang Technologies

If you’ve read this whole book up to now, what I’m going to say in this section will be no surprise to you:

RULE

Don’t choose exciting new technologies for your product simply because they’re there; instead, choose them only when you need them.

As computer people, we’re always quick to embrace new technologies. And as people looking to make a lot of money, we especially want to jump onto new technologies, being the first to write software for the technology. And that’s perfectly fine, provided you move forward carefully.

If Palm, for example, is going to release a brand-new handheld product with several new features and a fully revised operating system, you just might want to be the first to write software for the device. But before diving in, ask yourself, do you want to also support older Palm models? And if so, do you want to create separate products, one for the newer Palm devices and one for the older?

I can’t answer these questions for you; your answers will certainly depend on the particular needs of your organization. But remember, if you say you don’t care to support the older models, do you really want to risk everything on something that might not catch on? In the case of Palm, these days if they release a new product, it’s almost guaranteed to be a hit, of course. But if you’re writing for some brand-new technology (whether hardware such as a PDA device or software such as a new operating system), consider all the risks.

Some time back, Apple released their Newton product, which was a pretty powerful PDA. Unfortunately, for reasons I’m not aware of, the product didn’t catch on, and they discontinued it. What if you had invested all your money into software for the Newton? Similarly, around the time Windows 3.1 came out in the early 1990s, a company called Quarterdeck came out with a product called Desqview/X. This was, in essence, a complete competitor to Windows 3.1. It was a GUI system based on the popular X Windows system found on Unix systems, and it provided an advanced multitasking system. Now what if you had invested all your time and energy into writing software that would run on Desqview/X before you had a chance to see if it would last in the marketplace? (Hint: It didn’t, unfortunately. Quarterdeck did have several other popular products, and the company got sold to Symantec.)

Of course, these are extreme examples, talking about devices and operating systems. What about new technologies that run on Windows? For example, you might be writing a system that’s going to communicate with other computers, and you might discover a brand-new communications protocol that you’re sure will take off. Within no time, you can see every device on the planet supporting this protocol.

But, soon after you finish your product, you discover that a competing protocol (one that is clearly inferior) is the one that everybody embraces, rendering your product useless.

Note

If you work in the telecom field, you may have seen this happen between the protocols called SNMP and TL1. The TL1 protocol is far more powerful than SNMP. Yet, SNMP was the one that took off. Thus, companies that embraced TL1 instead of SNMP quickly found themselves with a problem on their hands: Go out of business or add SNMP capabilities to their products.

Remember that standardization is more powerful than better features. Suppose someone came up with a better electrical outlet that required rewiring buildings and was incompatible with the current electrical plugs. Would you care? No. It would be more trouble than it’s worth. Someday, such technologies as Windows, TCP-IP, and XML will be replaced with better tools, but not because someone came up with a substitute that worked a little better or had a few more features. Replacing a standard is like moving a mountain: It can be done, but there has to be a darn good reason for it.

The big question is, then, how do you know if a technology is worth pursuing? That’s more of a business question, and I would hesitate to give you solid business advice beyond engineering advice. However, here are some questions you can ask yourself:

• If you do a web search on a new technology, will you find other companies embracing it?

• Who is creating the new technology and how much marketing effort are they putting into it. (For example, is Microsoft creating it?)

• Does the technology seem like something users are really going to need? (Remember, needs and wants are two different things, and technologies survive based on needs more often than wants!)

• Does the new technology utilize current platforms? This might not always be important, but it’s something to consider.

SUGGESTION

Be careful with new technology. In this computer world, technology comes and goes so quickly that you usually can’t risk embracing new whiz-bang technology unless you are absolutely sure it will be a hit.