Shoring the Foundation

Nothing is perfect, least of all software. That's a fact of life over which we software users have very little control. As a practical matter, software

Nothing is perfect, least of all software. That's a fact of life over which we software users have very little control. As a practical matter, software developers cannot make their products perfect. They can, however, make decisions regarding which imperfections are addressed. The most fundamental imperfections are usually the absence of a significant feature or an awkward, incomplete, or flawed implementation.

Updates of digital audio workstations and other large programs tend to be focused heavily on adding new features. But these additions are frequently implemented in order to catch up with the competition's latest “hot” items or to take the lead with some cool new idea, rather than filling in missing functionality. Meanwhile, many older, fundamental features often retain the flaws that they have had for years. That is presumably because developers feel they make more money by selling the latest bells and whistles than by fixing existing features.

Some advances are obviously good and important; in my opinion, though, the No. 1 priority for serious users is to have robust and efficient implementations of the features they use every day. While new features may introduce new capabilities, adding a new feature should take priority over improving an old one only if the new feature obviates the need for the old or if the program previously had no feature for executing a basic task.

My own frustration with a program whose implementation continually presents obstacles to the simple execution of essential tasks has sometimes driven me to jump ship and use another program, despite the resulting learning curve and data-migration issues. In fact, I have participated in software migrations of an entire production department that were caused by the developer's inattention to the implementation of essential features. When customers depart from using a particular program, the developer loses money, not to mention prestige. Even when a problem is not severe enough to cause migration, the product's inability to easily execute crucial operations can create such a bad reputation that a developer can be dogged for many years.

It is easy to understand why making a program sexier is more attractive to a developer than throwing further resources at a feature that already “works.” But that reasoning is nonetheless flawed. It is similar to the reluctance of some businesses to invest in infrastructure because it produces no direct profit. The impact of such attitudes is often indirect, making the problems difficult to see until a crisis develops. Fuel is added to the fire when users are more tempted by “sweet candy” features than “nutritious vegetable” ones. Too often, end users realize only after buying a product's upgrade that the product can meet their crucial needs only with great difficulty, if at all.

Whether we are full-time production professionals, part-timers, or hobbyists, our interests are not served when basic aspects of our tools are left for years in an unfinished state, while new, less critical features are added by the boatload — frequently also in an unfinished state. Paid updates are not objectionable when they add real value.

On occasion, a developer does the right thing, such as when Mark of the Unicorn moved the track-addition commands in Digital Performer from contextual menus to global menus and greatly expanded keyboard shortcut capabilities. I noticed, enjoyed, profited from, and heartily applauded this change, which helps me in my daily work. On the other hand, Digital Performer's implementation of markers continues to exhibit several severe flaws that have existed for as long as I have used the program, and that have slowed my pace almost every time I've used it.

I encourage developers to reevaluate their priorities and consider that customers are most loyal when their greatest needs are well met, rather than when the shiniest bauble is proffered. In turn, end users have a responsibility to chew the ears off of developers about improvements to things that really matter, instead of simply accepting and working around flakiness and clumsy implementations of important features.