How Much Should Software Do? How Big Should Software Be?

The following really has nothing to do with language software per se, but is something I'm thinking of as I recently had to review educational software for school districts offered by a number of different companies. This industry, like many others, is showing a specific pattern.

Among the Feature Smells I mentioned earlier, one of the most common has to be Feature Bloat. This is when software tries to do too much. This is hardly something exclusive to language and educational software, but it certainly seems common in the industry.

To the non-technical, and sadly, to many technically-minded people, it might seem counter-intuitive that adding more features is bad. But it's usually better to do a few things very well than to do many things only adequately. Anyone who has had to bring up a piece of software and then wade through many baffling screens and controls will understand this problem.

I think that the problem occurs something like this:

A company has a product idea and spends time developing it. The company is looking for large customers, and gets a response from prospective customers of "This is nice, but we really need Feature X." So the company scrambles to add Feature X, hoping that closes the deal. Maybe it does or does not, but later the same company is selling their product, now with Feature X, and the new prospect asks for Feature Y. So now the original product is burdened with two new, possibly unrelated features.

The problem for the software designer is that you have to understand how all the features fit together. Most likely, because of time constraints, the system does not carefully model what the customer wants to do, and instead just adds the features as afterthoughts one after another.

The problem for the user is that, with all the features piled on top of each other, it becomes impossible to understand how the program is supposed to be used. Features go untried because the company providing the software has no time to document them or understand how they work together.

The problem for the software salesman is that every sale is an all-or-nothing deal. Either the customer buys the software to do everything, or the customer buys something else, and the software company gets nothing.

What is the alternative? Software should do a few things and do them well. Most importantly, software should be designed to work with other software, even from competitors. Many companies are reluctant to do this. It means having to learn about what other people are doing in your industry. It means competing on very specific features, and not on a general marketing spiel. It means responding rapidly to customer needs.

But these are all not only good things, but essential things to do in software design. Being aware of the industry means not wasting time rebuilding software features that other people already do well, and that you don't need to. Competing on features means being confident that you are the best in the specific thing you're selling, and not being weighed down having to sell badly-implemented features with it. Responding to customer needs means being able to respond with "no." No, our software does not do that, but another company's software will, and our software will work with it.

So what are the implications for education and language software?

First, stop building enormous platforms that have to be bought all or nothing. Build tools that let students, teachers, or schools do individual tasks they need to get done. Support those tools properly. When the customer wants new features, build the ones you know you can do well. Offer to work with the solutions that already exist.

It seems as though these principles should be obvious by now, but based on the software I've seen, it is amazing how often they are ignored in practice.