When do you decide code is "good enough"?
Posted by -Knockabout@reddit | ExperiencedDevs | View on Reddit | 58 comments
We have a responsibility to write code that doesn't break production or make future work significantly more difficult, but we also have a responsibility to get that code out in a timely manner. How do you balance these responsibilities? When is code "good enough"?
For some context...my team just finished a first pass at a project that was rushed in the interest of having something tangible to present sooner rather than later. It's only now that we are looking at part two of the project that we realize our architecture/patch jobs are insufficient and some kind of major rework is needed. Trying to go faster and focusing just on an MVP has cost us more time than if we had analyzed all of our requirements up front. I want to avoid this in the future. I am the only developer on the project, but work with SMEs and a project manager. Leadership is very interested in this project being in a final state as fast as possible, so the pressure is there to rush again.
MoreRespectForQA@reddit
I try to invert the question and ask product how much time they want me to spend on quality.
Rule of thumb:
0/100 bad idea.
30 product/70 tech debt we will deliver faster and faster with lower and be scary reactive to future requirements
60 product/40 tech debt things will remain steady
80 product/20 tech debt things will gradually slow down over time
100/0 we can move fast temporarily but will come to a crashing halt sooner or later.
BusNo4379@reddit
Landed on something similar by accident on my current project. Forced myself to invest in the architecture early even when it felt slow and now every new feature just slots in without fighting the codebases. The compounding effect is real.
How do you actually sell the flip to leadership though ? "Trust me, slowing down now means going faster later" is a hard putch when everyone just wants it shipped.
MoreRespectForQA@reddit
I generally dont. If something is for leadership's own good and theyre reluctant to hear it Im not going to push it too hard.
In the case of the 30/70 it didnt happen coz we sold it to leadership. it happened coz half of our work was blocked by other teams being slow and management werent paying much attention. so we just always refactored.
once we decoupled ourselves from other teams and started delivering features directly to the customer we were so fast people were shocked.
-Knockabout@reddit (OP)
I think defining it with higher ups would be nice. It's very loosy goosy, "go fast but also no tech debt".
MoreRespectForQA@reddit
yeaaaaa lot of managers will weasel out of making risky decisions which have the potential for blowback.
one of the reasons i like this question is because it usually makes product very uncomfortable. which is good, it should.
potatojesusgiggles@reddit
It works, it’s properly decoupled, it’s readable, it’s consistent with established standards and patterns in the codebase, an it’s covered with automated tests
Valuable_Ad9554@reddit
To be fair each and every one of these is a matter of degrees. There's no textbook answer for "to what degree" though, I think we develop intuitions and preferences for how to tweak the levers on each of these as we gain experience and apply that in each new setting based on the needs of the project etc.
ResistImaginary888@reddit
reminds me of the "technical debt" metaphor—pay now or pay later
g0fry@reddit
More like “pay now or pay tenfold later”.
ng37779a@reddit
The "cost us more time" calculation is missing some variables. Did that rushed MVP help secure funding, close sales, or buy you and your team time keep working on the project? Could you have continued development at all without something tangible to show?
Sometimes the choice isn't between "good architecture now vs technical debt later" — it's "working prototype that gets you runway vs perfect code that never ships because the project gets killed."
Also, given where we are with AI tooling, you could probably write much better specs now and rebuild that entire MVP in a fraction of the time it took originally. The architectural lessons learned from the first pass aren't worthless — they're your requirements document for the rebuild.
Quality matters, but so does momentum. If leadership is pushing for speed again, maybe the play is to acknowledge the technical debt explicitly, get commitment for a proper rebuild phase, and use this iteration to validate the business case for doing it right.
Or, the leadership are simply trying to grind you with unrealistic expectations..... unfortunately, that happens often.
YahenP@reddit
The code is good enough if you've met the budget and deadline, and the key requirements of the specifications. If the budget is exceeded, the code isn't good enough.
suboptimus_maximus@reddit
When it ships a multi-billion, multi-ten billion or multi hundred-billion dollar product.
I kid, sort of. But the older and more experienced I got the more I came to appreciate the value of code that gets the fucking job done and realized the guys who are blogging about the metaphysics of code quality and aesthetics only have the time and the luxury because they're not working on demanding enough projects.
BusNo4379@reddit
Completely agree but "gets the job done" means different things depending on context. For solo greenfield it's superpower. Legacy codebase with a team it's usually just debt with someone else's name on it eventually. Where do you personally draw the line ? Is it about team size, timeline or just vibes at that point ?
positivelymonkey@reddit
You just drew the lines? "It depends"
positivelymonkey@reddit
Wrong sub
DaveArthur@reddit
Surely the whole point of an MVP is to test the market, show potential investors etc. In that nature it needs to work and that's the only requirement. You can't spend months/years building an MVP it should be days/weeks for the purpose of testing the idea. If it works then it's back to the drawing board and start a fresh allowing for any new requirements etc
-Knockabout@reddit (OP)
I think part of the issue is that no one was structuring the project to actually be an MVP. It was called that, but...if we'd completed everything to our satisfaction, it'd have been 90% of the full app, with just a couple tangential features remaining. Not typical?
DaveArthur@reddit
I think there's a bigger issue here, should senior Devs be tasked with doing an MVP? I'd say no, they have too much experience, they need order, planning, structure to each project. This should be given to junior and mid level at the max. Knock it together, get it working from a min spec how doesn't matter, quick does.
jellenbogen@reddit
theres a difference between cutting features and cutting corners on the stuff you do build. cutting features is a legit MVP. cutting corners on architecture just means you're gonna rebuild it in 3 months anyway. I always ask "if this works and we need to extend it later, am I gonna be fighting this code or building on top of it?" if its the former its not done. sounds like thats exactly what happened to you guys. bummer but at least now you know what the actual requirements look like.
Effective_Hope_3071@reddit
It's always cheaper to do something right the first time than to do it twice.
The only time a brittle MVP needs to be shoved out the door is when the opportunity cost is higher than the cost of refactor. Was this for a contract in the millions?
The trick is quantifying the cost of the refactor.
-Knockabout@reddit (OP)
People were scared of getting axed by leadership, I think, but there were no clients ready to use it when the "MVP" was "finished". We probably won't have users until after this next part. I believe the deadline was pretty much entirely internal, as imposed by leadership. I did not assist in determining the due date for the project.
YK5Djvx2Mh@reddit
Are you on my team?
-Knockabout@reddit (OP)
God, I hope not. I live in constant fear of my coworkers recognizing me. That is why I tend to lie about a couple little things in any post like this, haha
Ma1eficent@reddit
Always start with KISS. Only add what you need.
Hoizmichel@reddit
In the past: when IT works, when it is well documentated and when it is performant. In the meantime: when it is better than everything the rest of the team would have written - example: when a sorting algorithm ist better than some O(n²) or even O(n³)...
vassadar@reddit
YAGNI. If the code not leak into other layer unnecessarily. Not over abstracted, then I'm fine with it.
Excellent_Repeat742@reddit
is prodpath.dev free to use
BusNo4379@reddit
Six years building things solo and then managing legacy systems I didn't write. I came to this question with scar tissue.
The answer I landed on, code is good enough when changing it doesn't scare you. Not when it ships, not when it works. When you can be wrong about it without it costing you everything.
Learned this the hard way. Rushed the core of my current project to get something tangible fast. It worked. Then every new feature started costing twice what it should because nothing was built to be corrected, just to ship.
The pressure to rush is real but if you're only one who knows what's under the hood, you're also the only one who can make that call honestly.
What's your read on the leadership side though ? Do you push back or just document the trade-off and move on ?
GoodishCoder@reddit
I don't necessarily think having to change things to meet future requirements always means you did something wrong unless you had a good idea of what's coming down the pipeline. Sometimes you get feature requests that need major changes.
That said, If you knew it was coming and designed it in a way that required major changes, the issue isn't the code it's the system design issue.
For me code is good enough when it meets requirements, is readable, is tested, addresses the current needs, and can reasonably be updated to meet expected future needs.
-Knockabout@reddit (OP)
I don't know that anyone involved ever really understood the problem this software is meant to be solving until recently.
GoodishCoder@reddit
If there's anything you learn from this, let it be to understand the problem before you try to solve it.
-Knockabout@reddit (OP)
Well, I knew that from the start. But the aforementioned pressure from leadership made the whole team throw it out the window.
htraos@reddit
Perceivable quality comes first. Always. Non-negotiable.
When you use a product, what you notice is how good it is, not how fast it was shipped.
BusNo4379@reddit
Right ! Users don't care about your architecture but they absolutely notice when something feels rough. The trick I've found is separating internal quality from perceived quality. You can have a messy codebase and a smooth UX (everybody know one case) or a beautiful architecture and a janky interface. One of those will kill your product faster than the other.
-Knockabout@reddit (OP)
This is what I believe because it's how I operate as a consumer, but not sure about leadership.
mxldevs@reddit
It works
If requirements change, I can feasibly swap things out, stick things on, and it works without having to rewrite half the existing codebase
There's nothing wrong with rushing a prototype. It will show you what works and what doesn't work, and reveal challenges that you didn't think about beforehand.
It's a prototype, it's designed to be throwaway. Don't get attached to your code.
The problem is when people decide the prototype is going to be the production version, and it's not always due to business pressure to ship ship ship.
BusNo4379@reddit
The prototype is throwaway part is the bit that always gets skipped. Everyone agrees with the principle nobody actually throws it away. The moment it works well enough to demo, it becomes the production version by default. I've started being explicit about it upfront, this is a spike. We rewrite before it ships. Helps a lot when you're the only dev and there's no one else to hold the line.
jakster355@reddit
You don't have to stop improving it, even when it's in production. Every industry and context is different, but my line is "is moving this now likely to provide more or less value". Sometimes a buggy new feature is still preferable to no new feature for a few weeks while the bugs are sorted.
-Knockabout@reddit (OP)
I'm curious, for something that might change in the UI, could it confuse users to have a new feature suddenly change on them? That's my main concern with pushing out a buggy new feature typically.
jakster355@reddit
Pros and cons. What happens if you don't release it? If it's entirely cosmetic, I would wait until it works perfectly
If it's a time saver, then you have to balance time saved vs time wasted due to existing bugs
LuckyWriter1292@reddit
When it works, there are no errors or bugs and we do what we need it to and I've got competing priorities.
zica-do-reddit@reddit
It works, it performs and it's reasonably maintainable (easy to understand and work with.)
newprint@reddit
Timelines.
The bigger philosophical issue: at some point in your life you have to let go everything you have created, be it finished or unfinished form.
siscia@reddit
Absolutely!
Engineering is where budget and requirements meets, and timelines are definitely part of the budget.
You cannot do engineering without a timeline!
chikamakaleyley@reddit
When i hit all the requirements because I got other shit to do
rahul91105@reddit
It’s never going to stop, once you deliver, new features will be requested and cycle will continue until technical debt slows everything down to a crawl.
Given you are the only developer on the team, I wouldn’t do any architectural/full rewrite level of change(s). Instead talk to your manager, tech lead and product manager about the future of this system. If this doesn’t have any new features going to get added, then just make sure this code doesn’t break under most circumstances and ship it.
If this has a potential to turn into an ongoing system with new development work coming in, then you should do a full rewrite and try to build a with those future features in mind. (You should probably consult with a technical lead/architect if this has a potential to be either a critical system (related to money, etc) or a lot of traffic/users will access this system.
pl487@reddit
Classic error. It always feels like that, but history has clearly shown that the up front approach tends to fail and the MVP approach tends to succeed.
Rework is okay. It's part of the process.
arihoenig@reddit
Never. It is never good enough, but once somebody loses the source code, at that point I am willing to call it finished
-Knockabout@reddit (OP)
A more blissful world for sure. We should all delete our git repositories and let the software live on forever within AWS's servers.
shill_420@reddit
In my experience, you literally can’t really ever balance these.
It’s an art, not a science. You have to play each situation by ear.
YMMV
-Knockabout@reddit (OP)
I often feel my work is more of an art than a science, so that makes sense to me. Though I wonder how much the "craftmanship" of development will go away with AI...probably this side of things will never be formulaic.
AbsurdWallaby@reddit
It's never good enough.
No_Quit_5301@reddit
Analyzing requirements up front is a myth and you’ll waste just as much time arguing over hypothetical what-ifs as you would needing to change from the MVP
Code is “good enough” when it meets the business requirement. Does it do what it’s supposed to and satisfy the customer’s need? Then it’s good enough
Taking into account technical debt of step 1 is a necessary part of step 2, but you often never get to step 2 if you waste too much time planning step 1
-Knockabout@reddit (OP)
This is less step 2 honestly and more step 1 but again. I'm not sure how to avoid that other than upfront requirements.
Esseratecades@reddit
Does the static analysis pass? This includes linting, formatting, complexity scans, code coverage, and security scans.
Does it do what I intended and only what I intended?
If the answers to both of these is yes then it's good enough and any additional changes are nice to haves.
ieatdownvotes4food@reddit
for me personally it depends on if there's a planned next step. if so I'll always refactor around that next step.
too much time is wasted around refactoring code that never gets a next step.. the next step once defined can really shape that refactor as well.
03263@reddit
When it's in production and meeting users needs
gingimli@reddit
My number one rule is don’t do anything that will be hard to change later. Besides that… whenever it works.