This past weekend I had the pleasure of running into one of my old classmates from college. After the typical pleasantries of catching up and reminiscing the conversation naturally shifted towards our respective jobs and what we do. With my friend being an in house database developer using Oracle and myself using FileMaker to develop custom solutions, we had a vigorous conversation about our respective career paths and the differences between them. At the end of the conversation I think we both realized two things: that despite our similar educational background, we both did completely different things; and that feature management was a very big headache for both of us.
The first problem we had was defining feature management. Being the good millennials that we were, we turned to Google and got the following definition from the Institute of Electrical and Electronics Engineers (IEEE)
“A distinguishing characteristic of a software item”
Needless to say this didn’t shed any light on the situation. The problem we realized was that defining a feature was too vague and too dependent on who you are dealing with. To a customer a feature might be to have a button on a layout that does something; with the end action of “something” being what is really concerning to the customer. That same feature of “something” might in reality be composed of several small features that the customer wouldn’t even consider; these are the features the developer would be worried about. For example, a customer might say they want a contact management solution that can manage their contacts; for a developer, “manage” contacts means being able to create, edit, delete, add phone numbers, add addresses, and a whole longer list of things.
The feature list the customer would list therefore is much different from one a developer would keep. The customer’s would include business goals and end uses, while the developer’s would include the actual nuts and bolts of how to implement those abstract business goals into a working solution. The true problem, and headache, comes when one list doesn’t perfectly match the other.
One example of this is called scope creep. This is when the customer’s list of desired features grows and keeps growing, causing development to be focused on these new features and therefore to lose track of the original intended purpose of the software or solution.
One thing that can help prevent this is proper question asking at the beginning of the project. As developers we are experts in development and not necessarily in the field of work the customer is engaged in. Taking the extra time to create assumption and terminology lists for a project can help put us in the customer’s shoes and give clarity to the customer’s view of a feature.
Another thing that can cause scope creep is having too many voices giving perspective. Opinions of what a feature should do will vary depending on who you are talking to on the hierarchy chart. With the end result being that there are multiple ways a feature is handled in the system; and with each way the feature is handled differently the developer has to build in more features to accommodate it. Two things can help prevent this. Making sure the person on the ground floor who will actually be using the software has a say in the development of it. The other is to have a lead point of contact within the customer’s organization who can arbitrate conflicting opinions. Both of these will ensure that the feature is true to the customer’s vision.
The end goal of software development is to create a solution that works for the customer and accomplishes all that they need it to do. By having proper communication and understanding of the differing views involved a developer can gain a clear picture of the features that the customer desires and build exactly what the customer desires.
