23:29
IMO, you don't need time to do good code. You just need to know how.
Everyone thinks "I can program, let's go!". Almost nobody actually keeps looking to 10 years down the road.
Could they keep maintaining it, could they add as many new features as there currently are without it collapsing under the new weight, etc.
Will it scale if the userbase grows from, say, 10k to 10m?
I mean, it won't right off--you will find slow points or whatever and need to fix it. The thing is, could you fix it without redoing everything?
Will it result in changes crawling throughout the codebase, or will it be limited to that section?
There's no such thing as the perfect program.
What there is, though, is the good enough program that can be changed as needed.
And I know that because I've worked on an open source project and seen it.
It started as a bit of extension code in VBA.
Then it was ported to C# and became a VBE addin.
Once it was in C#, it started having more and more features added. It got a parser (with many bugs!) and started to understand VBA code instead of just adding new static things.
Then, after a little bit, it started falling apart under it's own weight. We started adding a bunch of features for the next release, then realized what was happening, rewrote it, and released the next version 1.5 years later.
Literally everything was redone. It also had twice the features once we finished.
Since some things were just added because someone wanted to work on it. Eventually we feature-freezed, smashed bugs, and kicked it out.
Jump to a couple years later, it's needed bits and pieces redone, sometimes several times.
But it's still growing and is still easily maintainable.
Easy to add new things, easy to fix things (mostly, which is where some larger work is still going on at times to make it better), etc.
And that's where I found you don't need more time to write good code.
You just need to know how. Because writing bad code literally takes longer than writing good code.
Even in the first iteration.