Refactoring vs. Adding On Another Thing
When you get a request for something new, do you adjust existing code or build a new workflow? Read: "Everything Starts Out Looking Like a Toy" #207
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: Matt Wensing writes on today’s throw-away code and wonders: where will it go next? When you compare the arc of on-demand programming to what’s happened to other industries, it seems inevitable that auto-generated code will provide increasing value. This parallels other creative pursuits: when did you last edit your smartphone photographs manually? Edition 207 of this newsletter is here - it’s July 15, 2024.
If you have a comment or are interested in sponsoring, hit reply.
The Big Idea
A short long-form essay about data things
⚙️ Refactoring vs. Adding On Another Thing
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.
Links for Reading and Sharing
These are links that caught my 👀
1/ Smoothing data - Erghest Xheblati has an uncomplicated but important take on reviewing noisy data. Smoothing it helps you see the larger pattern outside of big spikes (which are also important to analyze, but not to generalize). Since you often don’t know and can’t repeat the source of a big spike, it makes sense to look at the metric in a zoomed-out context.
2/ How to be stubborn - Paul Graham writes on stubborn vs. obstinant, attempting to define the clarity of mind and purpose that often marks success. What I like about this essay is that it doesn’t just preach persistence, but defines persistence with purpose.
3/ Well typed - This is an oldie but goodie about using futuristic type in sci-fi movies. If you’ve seen Wall-E, you’ll recognize these images. And if you are a serious Pixar fan, you’ll also see the in-jokes here.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
Want to book a discovery call to talk about how we can work together?
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon