The power of self-discipline and good architecture

I am currently reading a book called the Mythical Man Month by Frederick Brooks, a classic collection of essays on engineering management, and while many particular aspects have become somewhat outdated (through agile methodologies or new communication technologies), much of the theory seems to stand the test of time.There is a section in the book which talks about the role of the software "architect," and in particular the way in which an architect works. First, the architect will design an initial system, and it will be very minimal and spare -- all extraneous "cool" features and ideas will be set aside for later consideration.The great danger facing an architect, according to Brooks, is when the second system is being designed:

The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a "big pile."

Brooks lists out several (rather technical) examples referring to things like "batch debugging without recompilation" and "managing a fixed-batch job stream," but the point is clear: good system design relies heavily on the self-control of the architect, and her ability to properly limit the scope of new systems, both by removing vestigial components and by preventing unnecessary additions.There is, I think, an obvious lesson for the creation of successful systems (programs, businesses, or laws, or others) of all kinds: that good complex systems grow slowly from good simple systems, and that this work is very, very hard to do.