Meeting Changing Requirements

A Software is as good as it’s ability to change to meet changing requirements.

In order to ensure that the Software can meet changing requirements, teams, sometimes, spend a lot of time trying to anticipate what those changes might be and putting up a structure (or architecture) that will ensure that the Software will be able to meet those anticipated changes when the time comes. To use a building analogy, the team tries to anticipate how many storeys the building may end up having and then digging the foundation deep enough for a five-storey building (assuming that is the anticipation) as well putting up a bare bones structure for the five-storey.

The thought is that once that bare bones structure is put up, then we can build one storey which is what we currently require but then when the time comes to add on storeys, it will be much easier to do that since we planned for it. There are, however, many drawbacks to this approach which is captured in the terms You Aren’t Gonna Need It (YAGNI). A lot has been written about YAGNI and it’s easy to learn what the drawbacks are. In short, it is not very efficient and a lot of effort gets wasted.

Another major problem with this approach, though, is that it can be difficult to know or measure that developers have done their job. Developers may be given a task to build a one-storey. However, if that culture exists, the developer cannot know they have done the work for sure even if they successfully put up the one-storey. Someone else can look at what the developer has done and say, you know what, business will likely add this requirement so instead of doing it that way, you should do it this way and so on.

Another issue is that since these, mainly, subjective changes are not captured in the requirements that the developers have to work with, it is hard to know where a project is at any point in time. Have we just completed a one-storey building feature or do we also have a bare-bones structure for a five storey building? Was this bare-bones structure tested the way that the one-storey building feature was tested? If not, can we say we have it or not have it? If we cannot say it is done, why bother with it in the first place? Many questions!

This is not to say that our code must not be able to anticipate changes. If we simply continue building without thinking of the foundation, we may get to a place where we need to add a storey but the building cannot support it and the only way is re-do the entire building. So our code must still be able to anticipate changes. It is not the intent but the how that poses the problem.

Unlike buildings, code can be easily refactored. To use our analogy, after putting up the one-storey building, it is possible with code to add more foundation so that it can handle another storey. Thus, what we need is not to try and figure out what the business will need in future since even the business people fail at predicting everything they want. Instead, our effort should go into ensuring that we code in a such a way it is easy to change the code to accommodate changes.

This way, we can judge the work that a developer has done by simply assessing whether it meets the stated requirement (i.e a one-storey building) and whether it follows sound coding practices such as if there are adequate tests, if there are no duplications etc. Once code is in an ‘easily refactorable’ state, we could add even 10 storeys when there is the need for it!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s