Comment by janalsncm
1 month ago
I have taken this approach with personal projects as well. In the past, I divided up the functionality into a bunch of neatly-organized classes at the beginning and then implemented each one in separate files. Big mistake. Much better is to put it all into one, ugly file until the kinks are worked out and then organize it later, at least in my opinion. It’s also much better for working in a flow state so that I don’t have to switch between 8 different tabs.
So even for personal projects, what’s most important is the ugly MVP that does the thing. It’s only after that works that I clean it up.
> Much better is to put it all into one, ugly file until the kinks are worked out and then organize it later
IMO this defer-until-needed approach depends a bit on having better tooling to use whenever the rework happens. Stuff like languages with statically-checkable types, good "Find Usages" IDEs, tests that exercise the overall architecture, etc.
When you can't count on those things, a constant gradual approach is needed to compensate.
It’s funny, I did a lot of python programming early in my career, and I didn’t realize just how afraid I was of refactoring until I started doing embedded work. Even as bad as the weakly typed C type system is, I found the compiler to be a godsend for changing my code later.