The next time you get a request to change an existing bit of code, check how you respond. It might be a small change, like adding a field to an existing model. Or it might be something larger, like adding a new and similar automation to an already automated process. You’ll probably think something like this: “should I fix it, or make it better for the long run?”
To solve it, you’ll assess what’s going on, and then adjust some code or create new code to fix It. Each of these approaches have different risks.
I don’t think there is an easy answer to this question. There’s a non-zero effort that needs to take place either way. When you create new automation, you might end up with a race condition that causes a new problem. When you commit to refactoring existing code, you might break something that works or take on an unknown amount of work to make the change.
Deciding to build or re-build
When you assess the request, you’re probably thinking:
-
Does this overlap existing functionality, using a different case?
-
Is it brand new functionality for something that hasn’t been done before?
-
Does it affect existing functionality, perhaps based on the order of operations?
When the request overlaps existing functionality
Suppose you have an existing process that runs when an account is closed won and someone suggests a special message that might happen for some closed-won accounts. This is a good example of overlapping existing functionality. Adjusting the existing workflow is likely the way to go, since you already have logic that activates when this condition occurs.
When the request is for new functionality
Let’s say you have a process that runs on an event – like a closed-won event on an account – and someone asks you to create a notification for a different event: adding a user. Because there are other ways a user could be added in addition to when they are a new user in a new account, you’ll want to create a new workflow for this. Adding that case on to your existing workflow will miss information.
When the new request affects existing functionality
If a new request changes the basic information available in another workflow – perhaps adding a new field to an existing data model that is important to know, like whether a customer is paid or past due – you might need multiple changes. This is tough to evaluate the effort because the initial new work might be easy to test, but the impact on existing work is harder to assess.
Test, and verify
Testing is the cornerstone to validating your new workflow (and your existing work) is performing as expected. You’ll want to test limits by throwing some nonsense information at the code including undefined/null input, and then test with existing records where you know what the output should be.
Building or rebuilding the existing code starts with understanding what needs to change. If you’re adding isolated functionality, creating new code has less risk. But pay attention – if you’re adding isolated functionality that also touches existing process, you might want to scope refactoring the work even if it takes a little bit more time.
There’s some unexpected value in avoiding future spaghetti code because you took a little longer to think and find the right way forward.
What’s the takeaway? The simple request of “could you fix this” or “could you build something new” often overlaps with existing functionality. One of the key first steps is to understand the requirements so that you can know if existing functionality is affected or if it needs to be refactored to support the new ideas.
