In software development, change requests(CR) often get a bad reputation. As developers and architects it can feel frustrating to have to redesign and change existing features(especially if the change request has a big impact on the existing system). However, we should see them as a positive sign for a product's success, evolution, and continued relevance.

Let’s explore why…

Reason 1 - Our system is used!

The fact that we get a CR means that at least someone tried our system and even better they see value in using it further because they want to improve it. When users ask for changes, it's because they're actively engaging with the software. They’re uncovering real-world use cases and scenarios that may not have been anticipated during initial design. This feedback loop confirms that the software is doing something valuable—and that users believe it can do even more.

Reason 2 – We have learned something!

Software, by its nature, is built to be flexible and adaptable (it is called ‘soft’ware for a reason). When new requirements or changes come in, it's a signal that both the users and we as the development team have learned something. Maybe the market has shifted, or the way people use the software has changed. These learnings are essential for keeping the product relevant and valuable.

Think of change requests as updates to a roadmap, informed by user experience and insights. They show that the system is evolving based on real-world feedback, which helps the product better serve its users.

Reason 3 – Our system is still relevant!

Software isn't static; it's an ongoing service. Unlike traditional products that may be complete upon release, software requires continual evolution to stay relevant. Needs change, new technology emerges, and the competitive landscape evolves. Rather than seeing change requests as setbacks, it’s more productive to view them as natural and necessary for a successful, long-lasting product.

Embracing change requests: a mindset shift

So I welcome you to change your mindset and see change requests as opportunities rather than problems. If we embrace the idea that software should grow and improve with user needs, then every request becomes a chance to refine our work and bring greater value to our users.

Embracing this mindset can help us to stay away from a ‘Big Design Up Front’ and aligns perfectly with the following quote from Kent Beck in his book Tidy First:

The future value of a system reveals itself in today realities, not yesterday's speculation

So, the next time a change request comes in, remember: it’s a sign of progress. It means your product is relevant, your users are engaged, and you're creating software that can adapt and thrive in a dynamic world.

More information

Tidy First?: A Personal Exercise in Empirical Software Design by Kent Beck | Goodreads