A recent experience on a committee project has me thinking about what is commonly called Feature Creep. It’s a phenomenon you might come across in other areas of endeavor like product design or station facility planning.
It happens to all of us. When working on a project, the dreaded question comes to you, yes, those two words: “What if?” You start wondering: If the project will do this, could it also do that? Maybe it would be nice if it also did this!
Then, unsuspecting, you start wondering if it can also accomplish yet another task.
This is Feature Creep.
While discovering ways to solve multiple tasks with a given solution can be fun, especially for engineers, it can also be costly and disruptive, taking you away from your original focused task. It’s easy to wander down this path; it happens to us all. It can happen on the workbench or even on the keyboard.
But though we tend to think of Feature Creep as a bad thing, that’s not always the case.
Recently I have been working on a technical document with a committee of notable engineers. A better cast of characters could not be found.
We were asked to write a simple guideline to describe a process for adding metadata. Yes, we had fun and discussed everything fully.
Then I said (yes it was me): What if we were to add a glossary so people could understand the terminology? Everyone agreed. Then someone else said: Let’s create and add some diagrams. Everyone agreed. Then the discussion turned to interfacing various systems; we realized this too would be good. Oh, and how about a timeline to show the origins of the concepts we were talking about?
Suddenly we were meeting weekly. (Thank you, Zoom.) But what had been conceived as a project of a few weeks took more than a year and a half.
The realization of what we’d done came upon us: This was no longer a guideline. It was now a handbook. Though we had removed sections and topics and were aware of Feature Creep, what had been envisioned as five pages turned into a manual of more than a hundred.
But it had value. Our organization had been patient with us. The final product was worth the wait. Here was an example of additions ultimately making a project better.
As committee chair, I had to make sure that the workgroup movers showed up to all the meetings. It was essential to keep things brand-agnostic and not let opinions weigh unduly. Rereading what we had created each week, we saw that sometimes we were too close to our topics. So pausing to review the scope of the project at times is crucial. Improvements are a good idea but adhering to a schedule is wise. Are additions really necessary? Will they cause you to the deadline?
But the lesson? Be open to suggestions at the outset and nimble enough to incorporate them as you go along. Don’t let fear of Feature Creep keep you from improving your product. But also, always keep your eye on the prize.
Oh, in case you are wondering, the document is NRSC-G304, “Metadata for Streaming Audio Handbook.” It will be presented this month to the Data Services and Metadata Subcommittee of the National Radio Systems Committee by our Metadata and Streaming Workgroup. The stellar participants of this drafting group include Jeff Detweiler, John Kean, Frank Klekner, Scott Norcross, Greg Ogonowski, Robert Orban and Steve Shultis. It was an honor to work with them. I hope the handbook will be helpful to our industry when the NRSC distributes it.
