Throwing out your first draft of work - is there a compatible methodology? [on hold]

Question

Are there any programming methodologies that take into account the concept that the first round of written code is likely to be not what you want to use? The most common thing I hear at the end of a project from a developer is 'If I could do that again, I'd do it so differently.' This is almost an exact mirror of the process a writer goes through after writing a first draft. The difference seems to be that writers then rewrite and rewrite again until they're ready to move into the editing stage, whereas developers seem to write and then refine their first draft with testing and refactoring.

I'm certainly no fan of trying to use alternative analogies to define the development process, but I do think there's value in recognising that your first draft is just to get ideas down, you need further rewrites in order to produce something worthwhile. I just don't think I've ever encountered a programming process or project methodology that recognises that, so I was hoping that the vast collective concious of Stackoverflow might have an idea of where I might start exploring this possibility?

Answer 1

Prototyping seems to address the problem in some way. The wikipedia article on Prototyping names an approach called 'Throwaway prototyping' which seems inline with your way of thinking.

Answer 2

What you are describing is called throwaway prototyping. The idea is that as soon as you have your preliminary requirements, you create a basic model of the system to show the user and/or customer what the final system might look like and how it might function (although there's no real functionality). The user provides feedback on this prototype.

If you wanted to utilize throwaway prototyping, my first suggestion would be to start looking at the spiral process model. However, I'm not familiar with very many methodologies that explicitly utilize throwaway prototyping. The more "agile" methodologies favor evolutionary prototyping or incremental prototyping. The only time I've ever personally used throwaway prototyping was to only prototype the user interface, as the underlying system was already under development and I used whiteboards and pen and paper for the prototypes.

Answer 3

Besides, this is one of Brooks's ideas which he himself found not the most effective after some revision: you've probably heard of "throwing away two systems after planning to throw away just one". Fortunately many such troubles can be overcome nowadays thanks to agile methodologies.

Answer 4

This is exactly the argument that Bruce Eckel is making here.

Answer 5

I would argue that the best thing to do is modularize very well. For example, if you're writing a kernel, the "Get the next available free memory frame" function should reside in its own function. That way, when you figure out that it's written in a really crappy way, you simple erase (of course you're using version control) and start from scratch. That way, your existing modules exist as a way to test your new code.

Going from start to finish and then start to finish again is an awesome way of going through a large percentage of the same bugs again.