This is more of a generic programming question, however I just thought it might be interesting to get some opinions here on the topic of people who find it difficult to start or continue projects because of perfectionism, whether it be based on constantly worrying that their code just isn’t good enough or just that they don’t want to continue until they’ve found the “best” way to do things.
Do you think it’s better for a perfectionist to
Just prototype and then refactor as things begin to shape up?
Continue to find the best architecture or design before starting or continuing a project?
Other? Please elaborate.
Personally I think that number 1 is more reasonable based on my own experiences in the past, where I’ve prolonged or even completely discontinued projects, simply because the code or “structure” just didn’t “feel” right and I had felt that I couldn’t come up with a better solution (at least before losing interest).
Naturally I lean towards number 2, but found that 1 actually brings results. Most times I find the “best” design/architecture after a few iterations of refactoring.
What I like about Go is that you can get your hands dirty quickly and basically get a project up and running fairly quickly, but still have the freedom to later restructure/create packages and add interfaces/closures to better the design.
I encourage my engineers to work in form of point 1, but it feels very dishonest because I have a personal tendency to work in the form of point 2. Sometimes I think social platforms like Github encourage type 2 behaviour, although the free private accounts on hosting sites like Gitlab allow people to be type 1 in private.
When I can’t start or continue with my project, it’s usually because I don’t really know how. Which usually gets fixed by hours or days of thinking.
My way of working is that I really think deeply about the high level design, stop and think if I stumble upon a problem with it and so on.
Once I have the high level design thought up, I jump in, and just prototype following the high level design and refactor details later.
When I find a problem with the high level design, I sometimes fully rethink it. Putting the existing code into the new, rethought design usually doesn’t mean, that I have to rewrite it all, I just have to correctly assemble the existing pieces of code into the new design.
[quote=“willis7, post:4, topic:4753, full:true”]although the free private accounts on hosting sites like Gitlab allow people to be type 1 in private.
[/quote]
I can’t even begin to tell you how you true this is for me
Most of the time I use 3 – transform structures into including what adds most value to the project, unless constrained by dependencies, in which case things get more complicated. Similarly about including other people. Size of included changes is max 5 ideas, but try to orient towards 3.
Perfect is the enemy of shipping. For work to have a real impact, it must get shipped, not only floated around in a state of possible perfection in your brain (or home directory).
Also, code lives. It is read hundreds of times more than it is changed. So perfectionism today is just delaying the time tomorrow when your colleague reads it and moves it closer to perfect for what the impact is that the business needs from the code. Which is quite likely farther from the perfect you were aspiring to when dithering over checking it in or not.
So you need to commit at some point, even if it’s a prototype that is exploring an idea.
But another reality is that prototypes tend to get shipped into production. One defense against that is to use a language where it is almost as easy to make production quality code as prototype code. Then your prototypes are already good enough, at least for v1.0. Using the Go standard library to it’s full extent (which is 100% production quality), and then continuing it’s idioms into your own code helps get you there. Training yourself to never ignore errors, not even in prototype code, gets you closer as well.
I’m a strong believer in upfront design, even if it’s only for a prototype. Even 10 minutes spent thinking and jotting down architecture on paper can be more valuable than several hours of hacking on code.
When I know what I’m doing, I’ll do it the right way, implementing the best architecture and stuff. But, when I’m learning something new, trying out a new lib or studying/implementing a new concept, then I’ll make it work and refactor later.
That’s very true, however sometimes I find that the line where things can get mixed up is where that 10 minutes gets turned into something much longer, but if it’s possible to just settle on a semi-decent MVP architecture or just a decent todo list, things definitely move a long faster and can save a whole lot of time.
For a developer who has to pay attention to the long-term stability of the product, 2 is unavoidable to prevent lock in effects. And this leads very clearly also to 3: Try to avoid frameworks that are interdependent. These will very quickly become wedged with each other and then hinder updates.
