November 26, 2025 at 12:00 am
Comments posted to this topic are about the item Done is Better than Good, which is is not currently available on the site.
November 26, 2025 at 10:09 am
I'm full on board with "Perfect is the enemy of good", but there has to be an agreed minimum quality bar. Agreed by all affected parties.
It isn't fun to support something where people have agreed on a quality bar that does not consider people supporting it. Even worse is the promise that what has been delivered will be fixed in the (mythical) phase 2.
It is expensive to recruit a customer. If there are quality gaps, then they must not be visible to the customer.
November 26, 2025 at 6:51 pm
Agreed though this is why you choose/ hire/pick craftsman that do good work.
Same for trades people/ handy people for building projects. They might take shortcuts and not be amazing but you have an acceptable level of quality
November 26, 2025 at 7:42 pm
I can't see the article, but with the premise I think it, like all things with a DBA, depends. If I am building a life support system and it is "done" but not "good", that'll come back to bite me.
If I'm building a calculator and it is done but not good, it might be good enough - https://discussions.apple.com/thread/255778836?sortBy=rank
A lot of it depends on the customer and the project. Perfection is something I like to aim for knowing that the target is going to be impossible. So I try to work with the customer to get the minimum viable product, the timeline, and then I target making the minimum viable product and if the timeline allows, I add in the nice to have features. Sometimes post go live, I am given the chance to continue working on it and can keep adding in the nice to have features. But I want the minimum viable product fully functional and to the best of my knowledge bug free before I start working on the nice to have features, but I design it with the nice to have features in mind so I'm not needing to rewrite the whole app to add a nice to have feature. Like (very bad example) if they want the ability to print to any printer the system can access, I am not going to hard-code in a printer list but instead read the printer names from the OS and use that to handle printing. If they want to have a hard-coded list of printers, I will try to future proof that by creating an admin interface where they can add/remove printers rather than having it hard-coded in the app. Obviously a very poor example because who in their right mind would have a hard-coded list of printers in their code, but I sometimes get surprised when I review old code...
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply