My mechanic "skills" provided insights in my software development career

When Software Breaks, We All Become "Penny Mechanics"

When I was younger, I had an old car. One day, the cooling fan solenoid broke, leaving the fan useless (some of you will know why starting the car would be a bad idea). Replacing it wasn’t an option - I didn’t have the money. So, I grabbed a penny (my budget for the fix) and jammed it in to force the fan on every time I started the car. It wasn’t the right fix; I knew that. But it worked. It got me where I needed to go, at least for a while.

In software, we do the same thing all the time. When something’s broken - or when the design didn’t account for a particular need - we improvise. We turn fields, functions, or workflows into something they were never intended to be.

Take the classic example: “This application field is supposed to hold ABC, but let’s repurpose it for XYZ because we need that data to flow into the backend integration.” It’s not what the field was designed for, but it gets the job done - for now.

The Cost of Improvisation

These kinds of fixes feel harmless in the moment. And sometimes, like my penny trick, they’re necessary to keep things moving. But every time we cut a corner, we’re trading short-term convenience for long-term problems:

• Hidden Complexity: Overloading a field with unintended data creates implicit logic that only the original implementers understand. Over time, this “solution” becomes a source of confusion and bugs.
• Technical Debt: Much like a penny jammed into a car’s cooling fan solenoid, these fixes are fragile. They work until something else changes, and then they break in unexpected ways.
• Lost Opportunities for Better Design: When we patch instead of fix, we miss the chance to step back and ask whether the underlying system can be improved to solve the problem the right way.

Why We Do It

In most cases, these improvisations happen because of constraints—time, money, resources. When the business says, “We need this feature yesterday,” you don’t always have the luxury of redesigning the system. Like my younger self, who couldn’t afford to replace the solenoid, you do what you can with what you have.

There’s also a mindset in software development that values cleverness. Using something in an unexpected way to solve a problem feels resourceful. But being clever isn’t always being wise.

Moving Beyond the Penny Fix

It’s not always possible to avoid shortcuts, but we can minimize their impact:

1. Document Your Intent: If you must repurpose a field or workflow, document why and how it’s being used. This helps future developers understand what’s happening.
2. Define Clear Boundaries: Make sure your team understands what’s “normal” and what’s an exception. Don’t let temporary workarounds become permanent parts of the system.
3. Prioritize Refactoring: Budget time and resources to revisit these fixes and address the root cause. Fixing the solenoid might not be urgent today, but eventually, the penny will fail.

Balancing Practicality and Discipline

In software, as in life, improvisation is a skill. But it’s a skill that should be used sparingly, with an eye toward eventual correction. That penny fix might get you down the road, but the real progress comes when you take the time to replace the solenoid.