Requirements Change: When Features Become Bugs

Anyone who has managed a complex piece of software for any length of time can attest to the fact that the requirements of the users morph and grow over time. Sometimes, individual parts of the original requirements may actually reverse. Things which were once required are now no longer allowed, and things which were forbidden are now required. This is when items that were once features of your software become bugs.

As a simplified example we will examine a piece of software from the fictitious company we all work for and love: XYZ Co. This piece is part of our internal toolset used by the Sales, Marketing, Finance and Billing departments to manage the XYZ Co. silly cat pictures subscription service. Our job is to build, maintain and extend that internal toolset.

The piece in question is the invoice generation software. This software determines what items belong on a customer’s invoice, and for what days that customer should be charged for them. At the time this software was built customers were charged for access to their selected number of cat pictures per month on the first of each month. Part of the requirement was that when a customer upgraded to the next tier that upgrade would always happen on the first of the current month, and cancels and downgrades would always happen on the first of the following month. This means even though a customer may end up with a pro-rated charge for an upgrade, there would never be a reason for a refund on a downgrade or cancelation.

Many months later, the decision is made to allow clients to cancel or downgrade at any time during the month and receive a pro-rated refund for the unused portion of their subscription fee. So the billing department files a bug in the issue tracker that clients are unable to cancel properly.

So how did this happen? It would be easy to say that this was simply a lack of communication between departments. It would also be so woefully incomplete as to be completely incorrect. It would be easy to say “X should have ….” As soon as the words “should have” enter the conversation, however, we know one of two things. If the word preceding is “I,” (or “we”, “our team”, etc) it means that either a process is missing or incomplete and needs to be addressed. If the word preceding references someone else, the speaker is looking to place blame.

Rather than looking for someone or something to blame, we need to fix the issue. Spending time spreading blame does not fix issues. So, we buckle down, update the business logic in the invoice generation software to allow any time cancelations and downgrades. We get our updates into production as quickly and correctly as possible, and we make sure to update all of our documentation to point to the new workflows, requirements, change-logs, and so on.

Now, we can go back to the question of how this happened. Remember that I said that calling this a failure in communications was so incomplete as to be incorrect? Here’s why. When the Finance department made the decision to allow pro-rated refunds for unused portions of subscriptions, they did not do so in a vacuum, any more than we built the original system in a vacuum. Instead, there are outside influences, coordination with payment processors, possibly legal issues, and a thousand other things our development team has no idea about in play. The Finance department can no more be expected to know how the invoice generation software is built, than our team can be expected to know the tax structure of our share holdings in Cat Studios of Burbank, Inc. (Hey, XYZ Co. is moving towards vertical integration.) So, to say that we failed to properly communicate the limits of our software, or they failed to fully communicate an upcoming business rule change misses all of that. Sometimes business rules change radically and quickly. Sometimes this happens so quickly that it is a fait accompli for any department not directly involved in making the change. This is not necessarily by choice. It might have been required last-minute to close a deal on the table. We don’t know. But we do know that we need to implement some sort of process. Perhaps one where Finance and other teams know that when business rules or workflows are changing they can fill out a simple form and submit it to the development teams, preferably with some pre-determined amount of lead time for the teams to update the software to match the new rules.

But what about our process? What can we do proactively to keep up with what all these other departments are doing? How about a process where we introduce ourselves and our tools to the teams. Explain a little about what our tools can and can’t do, and make that part of the on-boarding process for all departments that use our tools? In addition, we can advertise to those same departments when we are considering a new feature, and allow feedback. Also, every release should be announced so that everyone who wants to know what is going on in our world can stay informed. A regular sync meeting with other departments is probably a good idea as well. Nothing overly long or too often, just a short meeting to go over what is in progress, what changes have been pushed live, and a chance for them to comment on what they are working on that might affect us; on a weekly or bi-weekly basis.

Great, we have now put some processes in place that can assist us in keeping up with the rest of the company as their needs change. Does this mean no current feature will ever be a bug in the future? Probably not. Processes are, by their nature, not instantaneous, and sometimes requirements change faster than those changes can be run through our process. It does mean, however, that we are not going be blindsided by every little curve the company makes as they carve their path to cat picture supremacy.

No Responses so far

Comments are closed.

Comment RSS