Reducing “Constant Change”
There are many voices in the software industry arguing that the thing that describes our industry most is the fact that requirements are dynamic and customers are constantly changing their minds. This was the grounds for numerous methodologies and practices, all aimed at reducing the effect of this constant change. Some of these ideas are great. Others are just a buzz. Let’s assume, however, that most of these ideas can help addressing the problem of constant change in requirements and in the business environment. The question is, wouldn’t it be easier (and more cost effective) to try to at least reduce the problem of constant change (if not prevent it) before we are accepting it as force majour and trying only to deal with its damages?
Let’s stop for a minute and think: have we done everything that can be done to reduce what seems to appear as constant change? Here’s a short story…
The other day I was speaking with a developer who had to release a version of the product she was working on that same day. A couple of hours before releasing the version, she received an e-mail saying that a data item everyone assumed to exist in the protocol she had to work with is not available after all. The developer had to re-write parts of her code in order to retrieve the needed data from another source.
On the face of it, this sounds like a classic example of “dynamic requirements”. Let’s change our development process to handle these unfortunate changes we cannot control. Hmm… but did we do everything we can in order to avoid this “unexpected” scenario? Shouldn’t there be a person responsible for validating that different parts of the system interact as expected (before they are written)? Shouldn’t there be someone responsible for defining the protocol and validating its compliance with the requirements? Was that last minute “change” really unavoidable?
The fact is that we can do more to reduce the problem of constant change. We won’t be able to eliminate it, but we shouldn’t accept it as is. It is more reasonable to try to reduce the problem before we figure out a way to handle it consequences. Even when “unexpected” changes are the result of the customer changing his mind, you should ask yourself whether you did everything you could to prevent it. You can, for example, ask your customer more explicit questions, explain the tradeoffs and sometimes even (God forbid) demand an answer. Of course this will not guarantee zero changes, but it might reduce their number dramatically.
It seems like some of us are already so hung up on the idea of constant change, we are encouraging it ourselves. “We can handle frequent changes, so why bother with all the details now?”. Sometimes, you really can’t commit to all the details, but at other times, this is just an excuse for not doing professional work.
