I was trying to describe the meaning of a “feature” to a friend and they suggested:
“The makeup or appearance of the face or its parts” and “a prominent part or characteristic”, e.g. Pine trees were a feature of the landscape. As a consumer I think we tend to define feature as add-ons to the basic product, e.g. my car has leather seats and a surround-sound music system. Likewise software products often use features to describe additional attributes, e.g. my word processor includes a spelling dictionary feature. Maybe purpose or abilities would be a better english term, e.g. a phone has the ability to enable person to person voice communication.
Because I want to make the distinction between the business processes (aka: “The System”) and code meant to satisfy an application specific “feature” I look at it like this:
“Features” are what gets built on top of “the system” to implement an application, which is a collection of user-facing use-cases. Features are usually a part of the UI or UX automation. [“verify-payment” is not a feature, it’s a business process. “auto-enter saved payment info into the user controls” is a feature.]
A grand characteristic of “the system” is that many applications/web-apps can be build on top of (ie: using) your system. Batch or nightly jobs can directly target “the system.” In other words, applications use “the system” but “the system” should never be dependent upon an application or a web-app.
Both are created from code, so this distinction is a design choice, but it’s perhaps the single most important design choice and it’s hard to do it well. Having feature code in “the system” will destroy it. Having “system” code in your feature code just means you have a monolith. These choices are not asymmetrical. It’s hard to keep feature code out of the system and it’s extremely easy for system code to get placed into a feature.
A grand characteristic of a “feature” is that this is almost always what you’ll be asked to build by the product owner, your manager, or users. Very few stakeholders will know to ask for the business processes to be automated into “the system.” Human nature means that people think of the entire system as the collection of features that make up on applications.
Our job as software designers in to build a “system” on top of which many applications can be built. This is a system free of “features” but rich with business process automation. Features are important and they need to be built, but they are part of an application and not “the system.”
“Features” are provided by user-facing use-cases, often as part of an application or a web-app. Features help the user accomplish specific tasks and to gather input or feedback. They often have many interstitial steps ending with triggering “the system” to perform some business process (core use-case). “Features,” such as “image upload” or “select order item” are usually too fine grained to drive automation. The input from many “features” are usually required before significant automation can be triggered in “the system.”
“Features” are important. The user needs them to accomplish their tasks. A web site or an application can often pay for itself just based on the fine-grained automation provided by features. But there is a problem.
If you add “feature” code to “the system” the result is only a “feature.” It’s no longer “the system.” Features are application specific, the system is business specific.
