Designing for Change not Requirements

Change is inevitable in everything, so why not consider it in the design phase of a project. By designing for inevitable change this safeguards projects from a myriad of future hurdles. This post was inspired by the Weekly Dev Tips episode: https://www.weeklydevtips.com/episodes/requirements-and-change-with-guest-juval-lowy.

Typically projects usually start by trying to understand what the end-user wants and deciphering what the requirements are to implement this. These requirements are then broken up into bite size chunks, and development begins. But then what (almost) always happens is, the user comes back with a new idea or something was excommunicated and the project needs to change. This can be a painful experience to implement this new feature, especially if the work done to date isn't compatible.

By amending our approach to the design procedure to:

1. What is the requirement?
2. How could these requirement be achieved?
3. What could possible change later on?

The 3rd step above, could be viewed through many perspectives. The perspectives that are typically the most valuable are to consider for change later on, is how could we implement this that the developer can make changes easily, and how can we implement this such that the user can change their approach to using the tool. While the latter may be counterintuitive to implementing a tool that is responsible for one thing, it does pay off in the situations where users can utilise the software for more than one way!

By adopting this approach along with tracer design, the end-user/client is tightly interwoven into the development cycle, which has proven successful time and time again. Tracer design is the concept of sharing the works in progress as soon as possible with the client, and determining whether it hits the target or not. Rinse and repeat, and you'll get closer and closer to the target, this idea is similar to that of tracer bullets which light up where they land to adjust your aim closer to the target.

A great way to think of this during implementation is to make it as easy as possible put in & take out tools in your projects. For example, if you can make it as easy as possible to swap out the database implementation without breaking your project then this will improve cohesion in your project and make the inevitable changes much, much easier to handle.