<div dir="ltr">I remembered an interesting method that might be relevant in this discussion too. It is called the Mikado method and earlier was available as a free download, but now I see that the autors have published a book <a href="https://mikadomethod.wordpress.com/">https://mikadomethod.wordpress.com/</a>. The first chapter is available for reading at <a href="https://manning-content.s3.amazonaws.com/download/3/558b9be-92a7-4ebf-90ba-c7fdd830aea7/MikadoMethod_CH01.pdf">https://manning-content.s3.amazonaws.com/download/3/558b9be-92a7-4ebf-90ba-c7fdd830aea7/MikadoMethod_CH01.pdf</a><div><br></div><div>The method is meant mainly for refactoring existing code, but I think it could work for new code too. The idea is to set a goal and try a naive implementation. See what errors there are and set fixing them as prerequisites to the goal. Draw a tree of these prerequisites and how they depend on each other. The important and unintuitive next step is to revert all changes to a working state. Only then, choose an unsolved prerequisite and iterate the process until the initial goal is solved.</div><div><br></div><div>There are no discarded branches, but the graph of the things that were tried and their dependencies is illustrative of the development process and can be annotated with information about "why"s. Maybe this is a pragmatic middle ground between keeping everything and keeping only the final branch?</div><div><br></div><div>best regards,</div><div>Vlad</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 3, 2016 at 9:19 AM, Vlad Dumitrescu <span dir="ltr"><<a href="mailto:vladdu55@gmail.com" target="_blank">vladdu55@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Tue, May 3, 2016 at 3:29 AM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>But there's a reason why twists and turns might need recording.<br>
I don't know about you, but more than once I've had the experience that the<br>
'final "right" turn' was actually wrong, and to get working code I've had to go<br>
back to something I'd rejected on (what I know see to be) mistaken grounds.<br>
<br>
Now that doesn't mean everything has to be in the version we give to the<br>
compiler.  Keeping (possibly wrongly) discarded stuff is the job of the version<br>
control system.<br>
<br>
And of course an *idea* that is tried in one derivation line and then abandoned<br>
may turn out to be very useful for solving a different problem.</div></blockquote></div><br></span>This is true and would be useful, but I think I can see a problem (which might very well be the reason why it isn't something people already do): after a while, there will be literally thousands of discarded stuff. How am I supposed to search and find the alternative that works, especially if I am now working on a different problem than 6 months ago when the stuff was originally written? Is this search faster than starting from scratch? IMHO the answer is that what needs to be saved is a higher-level description, not a complete brain dump of the process.</div><div class="gmail_extra"><br></div><div class="gmail_extra">There is also a difference between what is interesting for teaching people (beginners) and what is interesting for future reference for the team that develops the code. These categories need different levels of detail, different kind of information.</div><div class="gmail_extra"><br></div><div class="gmail_extra">best regards,<br></div><div class="gmail_extra">Vlad</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>
</blockquote></div><br></div>