Following the Path

There is some advice that is very well understood in a few commercial software development circles, but I don’t think it has made it out to the general industry.

Software capabilities are by their very nature interdependent. They come in collections of related functionality and features. One convenient way to view these groups is as different paths that can be followed by the development effort.

With that in mind, the sage advice is to “never step foot on a path, unless you’re prepared to follow it”. It’s something I’ve heard many times, and repeated often.

It’s actually a simple idea. Once you start some development along a new path, the users will push hard to get further along. Nothing is worse that a ‘lite’ feature that sort of works. It’s existence will drive the users to demand that it get fully implemented, properly.

A great is example of this is if you are building an editor. Someone might come along and suggest an easy, simple localized ‘source code control’ like mechanism. Maybe you just keep a backup of the last set of writes. Simple right?

But it isn’t long before that doesn’t satisfy anymore. They’ll need more versions, a way to revert and some access to the underlying historic information. Eventually, they’ll want a full version of source code control with all of the bells and whistles. That would be nice, but getting there organically probably means the design has been compromised by history. Tentatively stepping on that path is only going to cause future problems.

As well, the existing development is probably midway through another set of paths. Is it better to thin out the resources to work on more half-done features, or focus on a smaller number and get them closer to being well-rounded and complete? People get drawn in by features, but they stay because the tools work for them. A half-done job is only great for marketing.

Of course, there are times with new products where one has to stake out their direction. It would be nice to only focus on one path at a time, but products live and grow so it helps to gives the users some type of preview of the future. Working on several paths simultaneously is both a requirement, and a sound long-term strategy.

Still, it is not a choice to be made lightly. Just because someone suggests a nice sounding feature, doesn’t mean it is a good idea right now. An unfocused system that partially does everything is essentially useless. A focused one that does a few things right is considerably more practical.