4 ms·

In my experience, if you have a medium sized task with multiple unknowns, it is best to prototype aggressively without a thought about quality, and then start a

by klabb3 1y ago

In my experience, if you have a medium sized task with multiple unknowns, it is best to prototype aggressively without a thought about quality, and then start a second iteration with quality in mind. The purpose of the prototyping is learning. It’s faster (yes) than prototype-then-fixup. Why? Because the ”live refactor” is harder than the greenfield writing phase. The new knowledge often makes the impl straightforward. It’s also better quality than design-then-build. The optimal architecture and modularization change with knowledge increase, which is best to get via experience. You can design fully upfront but it’s riddled with analysis paralysis - it’s notoriously hard (and slow) to predict unknowns. Sounds like good advice? Well, the hardest part isn’t to follow it – it’s to know upfront what size of task it is. If it turns out to be easier, you waste a bit of work (prototype-fixup is faster). However, if it’s bigger than you thought – you’re in the best possible position to break down the new problem into subtasks, with no wasted work.

perrygeo 1y ago
If you could package this up in a motivational poster, it belongs in every company meeting room. Speed and quality are not two opposing forces to tradeoff. We can have both. But we need to get rid of this silly, infantile, unwavering attachment to our source code files. Throw code away. All. the. time. The first version of code is, by definition, being built in the absence of critical information. Why on earth would we get so attached to that which was built in ignorance? In this case we're not "reusing code", we're throwing away knowledge! Why would you discard everything valuable you learned in favor of a code artifact written before you learned it? Throw away the code instead! Surely the code written AFTER gaining the knoweldge will be both faster and better quality. (and more clear, less tech debt, etc)
dsabanin 1y ago
Very well said. This is such an important point. I believe that if you truly accept what Hemingway said, that writing is rewriting, you get less attached to the idea of reaching the best design on the first try, and feel better when starting with a suboptimal solution. Of course this sometimes conflicts with organizational pressures, where that quick and dirty solution may be deemed as enough by some and you won't get to finish with the proper design. For me the trick is to consider first version just an internal stage of work on a feature, not even communicated outwards most of the times, until the appropriate design is reached.

by klabb3 1y ago

perrygeo 1y ago

If you could package this up in a motivational poster, it belongs in every company meeting room. Speed and quality are not two opposing forces to tradeoff. We can have both. But we need to get rid of this silly, infantile, unwavering attachment to our source code files. Throw code away. All. the. time. The first version of code is, by definition, being built in the absence of critical information. Why on earth would we get so attached to that which was built in ignorance? In this case we're not "reusing code", we're throwing away knowledge! Why would you discard everything valuable you learned in favor of a code artifact written before you learned it? Throw away the code instead! Surely the code written AFTER gaining the knoweldge will be both faster and better quality. (and more clear, less tech debt, etc)

dsabanin 1y ago

Very well said. This is such an important point. I believe that if you truly accept what Hemingway said, that writing is rewriting, you get less attached to the idea of reaching the best design on the first try, and feel better when starting with a suboptimal solution. Of course this sometimes conflicts with organizational pressures, where that quick and dirty solution may be deemed as enough by some and you won't get to finish with the proper design. For me the trick is to consider first version just an internal stage of work on a feature, not even communicated outwards most of the times, until the appropriate design is reached.