The Fundamental Law of Software Project Budgets
Description
A screenshot of a tweet from the account 'Programming sucks' (@UserInputSucks), whose profile picture humorously has 'CSS SUCKS' in a yellow box. The tweet text is a widely-known, cynical aphorism in the software industry: 'we never have the money to do it right but somehow we always have the fucking money to do it twice'. The statement is a sharp critique of short-sighted project management and business priorities. It describes the common scenario where stakeholders refuse to invest adequate time and resources for proper architecture, testing, and quality engineering upfront, citing budget or deadline constraints. Inevitably, the rushed, poorly-built product (the first time) is plagued with issues, leading to expensive maintenance, major refactoring, or a complete rewrite (the second time), which ultimately costs far more than doing it correctly from the start. This resonates deeply with experienced developers who have repeatedly witnessed this self-defeating cycle, making it a timeless and bitter piece of industry wisdom
Comments
15Comment deleted
This is the first law of software thermodynamics: entropy and technical debt always increase. The budget to fight it only appears *after* the heat death of the project
Our finance team follows an interesting consistency model: money is always stale when we propose refactoring, but instantly globally replicated the moment we declare a ‘greenfield rewrite.’
The only thing more expensive than hiring a senior engineer is not hiring one and watching three juniors build the same system four times while the CTO insists the third rewrite will definitely be the last one
The eternal software development paradox: management claims there's no budget for proper architecture, comprehensive testing, or adequate documentation - yet somehow the CFO always finds 3x the original budget when the hastily-built system collapses in production at 2 AM. It's like they're running a venture capital firm for technical debt, except the only exit strategy is a P0 incident and a team of burnt-out engineers rebuilding everything while the original 'savings' evaporate into overtime, lost revenue, and customer churn
The real CAP theorem: Can't Afford Proper, but Cash Always for Patchwork
Finance nixed two sprints for architecture and tests, then approved a six‑month “stabilization rewrite” - technical debt is the only compounding interest our CFO never budgets for
Our budgeting has at-least-once delivery semantics: we can’t afford to do it right, but we always find budget to do it twice
We have the money to task several people in parallel not knowing about each other doing the same thing. 🤦♂️ Comment deleted
But not enough to allow any of them do it right. Comment deleted
Because the first time is always a PoC, even if the client doesn't know it. Comment deleted
Agile ^^ Comment deleted
Welcome to agile. We prefer: Endless arguments over proper workflow Speedrunned code over optimal and documented code Making customer involve in this fuckery over negotiating properly Ever changing requirements over stable plan Comment deleted
Agile: The way to be flexible in your workflow. Fixed schedule, so your flexibility comes in your choice to either work all nights or work weekends Comment deleted
You can always fall back on Waterfall. The project will be finished on schedule... at a point when nobody cares anymore. It will be just as the client described... but not quite how they wanted. And, of course, the project will be built on a solid framework... one that has critical issues and hasn't been supported for over a year, but hey, how were you supposed to know? Comment deleted
I realized, I have freedom of speech for a reason Comment deleted