I think there's a myth that rewriting software is bad, or at least a symptom of badness, and "reusing" software is ideal. But writing software is really like creating plans: plans for what the machine should do. Of course there is much room for reusing old plans as components of your new plan. But still every plan must be about what is needed at the moment, not about reusing existing plan-components. In human communi…
> 14. In the long run every program becomes rococo - then rubble.
And;
> 15. Everything should be built top-down, except the first time.
I think these are helping to understand the lifecycle of a project.
A first top down design should be understood as a draft, a direction. With experience these drafts get better, but the act of bottom up programming is necessary to discover details, problems and requirements that inform a more robust and flexible design.
A rewrite can be partial or total. Maybe it is enough to refactor some components, maybe a new design was discovered during the initial iterations, which yields a system that composes and evolves more robustly and works better as a whole.
As a web developer I program user facing applications, so there is always a kind of pressure to have highly domain and feature specific interfaces. Just get it done, move to the next.
But by learning from the Lisp world [1], Out of the Tar Pit [2], software design books [3][4] and the pain of experience, I've come to the conclusion that there is a better way. There is often a general layer that wants to be discovered that we can use to build the needed features. A workflow, framework, DSL or maybe just a bunch of functions or a data model.
This layer is often very hard to get right the first time around, especially if we don't have strong analogies already. It is often more natural to discover it by writing or trying to write the specific code first. Premature abstraction is the root of all evil.
But also [0]:
> 7. It is easier to write an incorrect program than understand a correct one.
We should be brave enough to move forward, while assuming that we're probably wrong. Scientists often practice this principle and try to figure out in what ways they _are_ wrong. I think this is a good way to approach programming too.
[0] http://www.cs.yale.edu/homes/perlis-alan/quotes.html
[1] https://dspace.mit.edu/handle/1721.1/6064
[2] http://curtclifton.net/papers/MoseleyMarks06a.pdf
[3] https://web.stanford.edu/~ouster/cgi-bin/book.php
[4] https://mitpress.mit.edu/books/software-design-flexibility