Martin, there is much wisdom in what you write. and, the text you cited (i summarize as "write once, throw it away; write it again another day") is also very powerful. the problem, ultimately, is understanding what the problem to be solved actually is, wrestling with that problem until you really understand it. (well, "imho". :)
> I've certainly noticed in the software I write that complexity tends to > be a graph roughly like: > > complexity > │ > │ --- > │ / \-- > │/-/ \-- > └───────────── time > > > As my understanding of the problem and various solutions increases, I > can reduce complexity. > > The more complex solution(s) however, *do* usually work and are "good > enough", in a way. yeah. there's a third dimension, something like "good enough (in a way)". i find that my software tends to get to somewhere with high complexity (maybe not the highest, but, still), with a reasonable value on the "good enough" axis. then, the urgencies of time, other projects, [boredom?], etc., tend to leave it there. (maybe the "suckmore" philosophy.) one other thing i've noticed in my own large programs, fwiw, is a tendency for most of the complexity (and so most of the bugs) to concentrate in one small portion of the code (one or two "pages", back in the days of using printers). anyway, thanks for your e-mail. cheers, Greg