I like the idea of “Spike and Stabilise”.
Which means, prototyping in this way, but at the point it is actually delivering value, stabilise.
Of course, it’s never as simple as that, but there’s certainly a place for this technique.
Throw away your first draft of your code
71–80 of 230 posts
Re: Throw away your first draft of your code
#72The temptation to throw away all of your code - be it a prototype or a "grown" code base - arises often. Often it is a bad idea. I get it, though, there is an inherent attractiveness in the idea of starting fresh from a clean slate. Except, more likely than not, you'll soon find yourself in a similar situation to the one you started from. The fundamental problem is that it is easy to underestimate the edge cases. Sur…
Throwing away an established code base is a completely different thing from throwing away a few-days-old prototype, and not what the article is suggesting. The points you mention don't apply to the prototype case.
Yeah, this thread is a somewhat strange read. People don't seem to understand what "draft" or "prototype" means. Odd.
Re: Throw away your first draft of your code
#73I try to structure my code so that it can be easily tested and it is modular enough so that you can swap implementations with fair ease.
This means I can iterate much quicker - I can have code that works and is good enough for now and I can later on improve it and also I can suitable test coverage that can confirm the new improved implementation works as expected.
Code that is organised this way is also rather easy to understand and test perform a function of documentation - which means someone else can get familiar with it and work in a short period of time.
Re: Throw away your first draft of your code
#74Currently I'm writing mostly C and C++ and I find it very useful to write prototypes, either in the target language or in Python, to experiment with ways to modularize the code and how the modules will communicate.
I only disagree with throwing the code away. On the contrary, sometimes I even use the last prototype as a sort of "executable documentation".
That strategy indeed saves me a bunch of time. However, at least in my experience, I didn't have success applying that to modern front-end dev: the complexity is frequently so high and the dead-ends are so numerous that I prefer to buckle-in for the rough ride and proceed to the code right away.
Re: Throw away your first draft of your code
#75I like to build my first version in one file with as few abstractions as possible. No helper functions, unless absolutely necessary, just straight-forward code. Building good abstractions later on is a lot easier than starting with wrong ones in the first place.
I've always done it like this as well. Initially I did it for the most obvious reason: it gave me the working software that I needed the fastest. Then later on, I always found it to be the best way to find natural abstractions as you go.
Re: Throw away your first draft of your code
#76I'd rather do the Ship of Theseus thing and just harden the prototype as required, and only when faced with real-world evidence. The problem with rewriting is that sometimes you face second-system syndrome[1] where you overengineer everything. Believe me--it happened to me at Groove Networks after Lotus Notes (ask your grandparents about that). [1] https://en.wikipedia.org/wiki/Second-system_effect
Yet I find when rewriting from scratch there's a countering force of simplification where I find myself thinking "We spent way too much complexity on that part, and we can entirely do away with that other part, and we turned out never to use features X and Y."
> "...and we turned out never to use features X and Y."
THIS. Often, the best way to start the rewrite is to go straight to the database, and start asking "what allowed values for all these fields have never actually been used?".
EDIT: Whether it's rewriting, or refactoring, or adding some "if( Deprecated_Feature_Allow !== true ) ... ErrorDie( Feature_Deprecated )" logic here and there, or updating training material, or whatever - knowing that Software_Feature got ~zero real-world use is d*mned useful.
Re: Throw away your first draft of your code
#77I'd rather do the Ship of Theseus thing and just harden the prototype as required, and only when faced with real-world evidence. The problem with rewriting is that sometimes you face second-system syndrome[1] where you overengineer everything. Believe me--it happened to me at Groove Networks after Lotus Notes (ask your grandparents about that). [1] https://en.wikipedia.org/wiki/Second-system_effect
Yet I find when rewriting from scratch there's a countering force of simplification where I find myself thinking "We spent way too much complexity on that part, and we can entirely do away with that other part, and we turned out never to use features X and Y."
Yeah, that makes sense too.
I think it just boils down to "keep writing systems and you'll get better at it." But there's no bait on that kind of link.
Re: Throw away your first draft of your code
#78Earlier quoted context omitted.
Yet I find when rewriting from scratch there's a countering force of simplification where I find myself thinking "We spent way too much complexity on that part, and we can entirely do away with that other part, and we turned out never to use features X and Y."
> "...and we turned out never to use features X and Y." THIS. Often, the best way to start the rewrite is to go straight to the database, and start asking "what allowed values for all these fields have never actually been used?". EDIT: Whether it's rewriting, or refactoring, or adding some "if( Deprecated_Feature_Allow !== true ) ... ErrorDie( Feature_Deprecated )" logic here and there, or updating training material,…
Agreed--every software engineer I know loves deleting useless code.
But this is not incompatible with refactoring instead of rewriting.
Re: Throw away your first draft of your code
#79This advice depends a lot on how your "first draft" was coded to begin with. The concept of "first draft" shouldn't exist as code. You design it properly, then you implement it properly. Now, if for some reason, and there are plenty of good ones, you cannot do the former, then sure, you pay that price by redoing some work. But, at that point, you do the same thing you should have done: you design it properly, then yo…
> You design it properly
And how, if I may ask, does one design it properly?
Re: Throw away your first draft of your code
#80Not on this scale but it has happened to me on a few occasions that I've lost several hours work for some reason (including no autosaves).
After the initial despair I know from experience I need to quickly try and recreate what I've lost while it's fresh in my mind.
It takes much much less time and I always feel that I've done a cleaner job second time around.
At times like that has occurred that this is the way to do it but I've never been able to bring myself to adopt this as policy.