Penny-Wise and Pound-Stupid
One summer, during a programming internship, a fellow intern spilled her drink all over her keyboard. Not water—soda. Sticky, syrupy residue quickly dried between the keys. The keyboard was a lost cause. The keys stuck down when pressed, only popping back up minutes later.
Panicked, she worried her boss would be upset about the ruined company property. Determined to fix it, she took the keyboard apart and began cleaning. After more than an hour of painstaking effort, her boss walked by and asked what she was doing. Embarrassed, she explained.
He laughed and asked: “How much do you make an hour? How long have you been working on this? And do you know how much a keyboard costs?”
Finally, he added, “You’ve spent more time on this than the keyboard is worth. Just toss it and grab a new one from the supply closet. It’s not worth your time.”
In the software industry, we often fall into the same trap: penny-wise and pound-stupid. Like that intern scrubbing a ruined $14 keyboard, we spend time and resources on things that just don’t pay off. If every decision were as clear-cut as the sticky keyboard, this wouldn’t be a problem. But in engineering, costs and benefits are rarely so obvious. Still, I’ve noticed a few situations that feel just like that intern’s frantic keyboard cleanup.
Outsourcing
Does this sound familiar? Someone higher up the food chain has lunch with a buddy who brags about hiring cheap programmers from halfway across the globe. The higher-up comes back energized. By afternoon, they’re in a conference room, pointing at numbers on a whiteboard.
Later that day, they stride into the developer bullpen, grinning widely:
“Good news! We’ve got a couple more developers starting tomorrow. I’ll send you the deets, but long story short—we’re about to crush these deadlines. You’re welcome.”
Then they head off to the pub to celebrate.
Whenever this happens, my heart sinks. What looks like a productivity goldmine to them is a nightmare for us. The work doesn’t get easier; it gets harder. And to make it worse, they’ve now set accelerated delivery expectations.
This is classic penny-wise and pound-stupid.
Before pulling the trigger, someone in the business ran the numbers. They compared the cost of hiring a US developer versus someone from a less expensive part of the world. Two or three developers for the price of one—it’s a no-brainer, right?
Wrong. What they didn’t factor in is how productivity nosedives when the team has to onboard and collaborate with an outsourced group. Developers who were fully dedicated to the project now spend chunks of their time ramping up the new team members. And those new hires? They won’t contribute at full capacity for weeks or months. Instead of speeding things up, the project falls behind.1
The slowdown only pays off if you’re prepared to take a hit in the short term.2 If you’re not, you’re bound to be disappointed. To make matters worse, time zones and language barriers create constant friction. Unless you can neatly partition work into isolated chunks that remote developers can tackle independently, collaboration becomes a bottleneck.3
Here’s how it usually plays out: someone assigns a Jira ticket to the outsourced team. While the local team sleeps, the remote team hits a snag and needs to ask questions. By the time you’re back online, you realize they’ve misunderstood the task entirely. You clarify, but the next day, it’s still off. This cycle repeats until someone finally stays late for a video call, only to find that, because of language differences, even face-to-face communication doesn’t solve the problem. None of this shows up on a balance sheet, but it drags projects down.
It’s important to emphasize that these challenges aren’t a reflection of the skills or dedication of outsourced developers. They’re some of the brightest, most well-intentioned people I’ve worked with. The problem lies in systemic barriers—communication gaps, time zones, and mismatched workflows—that make effective collaboration incredibly difficult.
To the corporate accountant, outsourcing might look like a bargain. But if they saw the wasted time and effort up close, they’d think twice.
Tools
Joel Spolsky said it best:
Top-notch development teams don’t torture their programmers. Even minor frustrations caused by using underpowered tools add up, making programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer.4
There’s a shocking tolerance for poor tooling in software development today. Too many developers are fumbling through incomprehensible Jira workflows or wrestling with Microsoft Teams just to format a code snippet correctly. It’s unacceptable.
Project management and communication tools are at the core of a developer’s day-to-day, especially with so many people working from home. When those tools are clunky or inefficient, the constant friction is soul-crushing. It’s death by a thousand paper cuts. Wasted minutes turn into hours, which snowball into days. Lost pennies turn into dollars, then thousands of dollars. Like Joel Spolsky says, it adds up.
But the bigger cost isn’t inefficiency—it’s morale. Nothing says “we don’t care about you” quite like ignoring your employees’ tooling preferences. It’s like handing Fisher-Price hammers to workers building a house. It’s insulting. If you want people to feel like professionals, give them professional-grade tools. Don’t settle for whatever happens to be bundled with your Microsoft license.
The same disrespect for tools shows up when companies force developers to use a specific operating system. Don’t make Linux programmers fumble around in WSL on Windows. Let the Mac folks stick with their preferred tools. With virtualization, there’s rarely a good reason to mandate one OS over another.
At the end of the day, any savings from skimping on tools is quickly overwhelmed by the productivity loss they cause—and the damage they do to your team’s morale.
Busyness
When management talks about productivity, they’re rarely focused on teams creating real product value—it’s just too hard to measure. Instead, they pick something easier to track as a proxy for productivity and work on optimizing that. In software, this leads to yet another classic penny-wise and pound-stupid situation.
For many managers, maximizing productivity means keeping every "resource" —aka programmer—constantly engaged in work. The logic is simple: if someone isn’t actively working, money is being wasted. But this mindset comes with a much greater cost.
First, it leaves no time for non-work activities that are essential to long-term success: training, researching, cleaning up, planning, and yes, even resting. Modern software processes have stripped these activities down to the bare minimum, favoring a relentless churn of sprint after sprint. Programmers are stuck picking up tickets, cranking out code, and repeating the cycle endlessly. To a manager, this might look ideal—everyone’s busy! But in reality, when you cut out the “maintenance” work, you end up with disengaged, burnt-out programmers. Even your lawn mower can’t run nonstop—it needs gas, oil changes, and basic upkeep, or it breaks down. Unfortunately, developer maintenance is an afterthought in many organizations.
The second reason comes straight from Toyota, which figured this out a long time ago. Productivity isn’t about keeping every part of the system working all the time—it’s about optimizing throughput, the rate at which value is delivered to the customer. If there’s a bottleneck, continuing to push work into the system doesn’t help; it just stacks up and slows everything down. Toyota discovered that sometimes the best way to increase overall efficiency is to let certain parts of the system pause until the bottleneck is cleared.
In software, the same principle applies. When developers are constantly churning out code but there’s a delay in testing, reviewing, or deploying it, the “inventory” of unfinished work grows. This doesn’t just delay delivery—it increases the chances of rework, bugs, and miscommunication. Instead of forcing everyone to stay busy, it’s often better to focus on clearing bottlenecks and maintaining a smooth flow of work through the system.
The managerial instinct to keep everyone working all the time might feel productive in the moment, but it’s shortsighted. It creates larger inefficiencies in the system—and leads to burnout in the process.
Conclusion
In the rush to save pennies, we often lose sight of the dollars slipping through our fingers. Whether it’s forcing developers to work with clunky tools, outsourcing without understanding the hidden costs, or treating people like machines that can run without rest, the result is the same: inefficiency, frustration, and burnout.
Great software isn’t built by cutting corners—it’s built by investing in your team: giving them the tools, time, and trust to thrive. That means giving them the tools they need to succeed, respecting their time and expertise, and prioritizing value over busywork. Productivity isn’t about keeping everyone constantly working; it’s about enabling your team to do their best work, sustainably.
So, next time someone pitches a penny-wise shortcut, think about the sticky keyboard. Sometimes, it’s better to throw it out and get a new one.
Sadly, many companies skip onboarding entirely, which ends up being even more costly. New engineers remain inefficient for longer as they stumble around in the dark, while your existing developers are bombarded with questions about basic processes, architecture, and vision.
Fred Brooks, in the The Mythical Man-Month, has even more to say on this topic: https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Smart companies, like Basecamp, create small teams—just a couple of developers—who can collaborate closely and tackle six-week projects with a high degree of autonomy. This approach allows them to hire talent from anywhere in the world and make it work. Most companies, however, rely on ticket-taking Scrum, which is the worst-case scenario for outsourcing.