Making a change
When making a change to an existing piece of software I think there are broadly 2 options;
- Get in and out, change as little as possible
- Restructure the code to fit the new requirement
The lure of option 1 is strong, less change means less likelihood of breaking any existing features, I'll have less work to do and it'll be done quicker.
Option 2 looks like a process for a significant new features, it looks like more work and greater risk of breaking something. However when taking this option is adding code to work around the current behaviour is;
- A missed opportunity to improve the design and
- Progress down the road to a big ball of mud.
Making it better
When working with any code-base I owe it to my colleagues and future self to improve the software I work with, or at the very least not fuel the software rot that makes the software more expensive in time and effort to test and/or change.
What I am trying to do more often, is to consider that the requirements, assumptions and trade-offs that were made when the system was written were very probably not the same as they are now. We will always know the most about the problem when we've finished rather than before or during development. The code now facing me solves a different problem than the one I face right now.
As part of the analysis for any change I have to take at least a moment to decide if I can extend the current design or is a bigger change required to cope with new changes;
- Does the data structure still fit?
- Is the component communication model still appropriate?
- Is that where the data should live?
- Does this method actually belong here?
- Is this thing now doing too much?
- Is there now too much client/server chatter?
Make it easy
At it's heart I think the question is, Does sticking to the current design make the software better or worse?
Software should be easy to change without anticipating every possibility up-front. I'll assume this idea was in mind when the software was first written. If I don't follow through with this ease of change assumption then I'm going in the opposite direction and that's not the kind of software I want to deal with in the future.