Throw away your first draft of your code

Then email me the PDF and store the papers in a box, and a couple of days later I start the v2 (same process), then v3.

By v4 it's 'good'.

I also use the same method on my 9-5.

I take VERY seriously the Abraham Lincoln quote “Give me six hours to chop down a tree and I will spend the first four sharpening the axe” on almost everything.

I consider the v1, v2, v3 as the "sharpening the axe" and the v4 on the actual cutting.

In that spirit, the article has a similar approach, as the v1, v2, and v3 may take you down an (more than) imperfect path.

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Granted Joel is taking about a wholesale rewrite of proven / established code. Code and has had had the advantage of time.

Personally, I end up rewriting parts of my code often. It usually takes a mile for me to find exactly the right way it should be based on how are people use it.

You absolutely should rewrite prototypes, and re-factor important chunks of code. I rewrote something 3 times today, it was better each time.

At the same time you should be wary…

One test is worth ten thousand opinions. What are a thousand tests worth?

Plan to build and deliver an expedient first version, then have a technical debt jubilee before building the second.

Build v1 in the most reasonable expedient (including not-scaled-up) way to deliver a reasonably full first feature set. See how it runs, what the users like/dislike/need/want, where are the rough edges both externally & internally, what the load cases look like, on various components, etc.

You'll find 80%-90% of your surprises with this.

Now, use your quickly-won knowledge of your actual system to plan and build the durable and scalable version.

Despite my intrinsic approach having always been about planning, generalizing, etc. (premature optimization?), I was fortunate enough to be in a situation in one startup where I decided to do this, and it worked out amazingly well. V1 got out fast, without worries about tech debt. Building the 2nd version based on actual knowledge and and the v1 tech debt jettisoned, allowed a 'real' version to get out faster and better.

There may be some problems with mgt politics, and it interfered in the above product also, but it does have much to recommend it.

If you build a prototype and happen to nail it then why not iterate?

Or perhaps you wrote a prototype and specific components/module feel sound?

Authors suggestion feels sound as a question you should ask yourself & seriously consider, more than a strict principle.

* Start with a blank `main` file and proceed linearly down the page, executing as I go.

* Gradually pull out visually awkward chunks of code and put them into functions with no arguments at the top of the file.

* If I need to parameterize them, add those parameters as needed - don't guess at what I might want to change later.

* Embrace duplication - don't unnecessary add loops or abstractions.

* Once the file is ~500 LOC or becomes too dense, start to refactor a bit. Perhaps introduce some loops or some global variables.

* At all times, ensure the script is idempotent - just highlighting the entire page and spamming run should "do what I want" without causing trouble.

* Once the script is started to take shape, it can be time to bring some OO into it - perhaps there is an object or set of objects I want to pass around, I can make a class for that. Perhaps I can start to think about how to make the functionality more "generalized" and accessible to others via a package.

This is literally the only way I've ever found to be productive with green field development. If my first LOC has the word "class" or "def" in it - I am absolutely going to ripping my hair out 12 hours later, guaranteed.