> it needs to be iteratively developed with constant feedback from the work itself and it's reception, if it is to be successful. There's a danger here too in

> it needs to be iteratively developed with constant feedback from the work itself and it's reception, if it is to be successful. There's a danger here too in that you can iterate on a design in a "monolithic" way where you iterate over a brittle design that's still hard to work with years later because you need to reload the entire system into your brain to make sense of it again. Looking at Unix as an open source design success story, it was designed in relatively well-defined "layers". So for example it can get away with making literally everything a "file" with a common file interface, even if you're actually working with a physical peripheral or a "black hole" like /dev/null. And on these layers you can build all kinds of different implementations. I try to push for a similar approach even on proprietary projects because if we can compartmentalize what we need to know to work with the pieces of our systems, they'll be easier to understand with less effort than if we need to understand everything about them before iterating on them. And this can be passively "encouraged" by how the work is divided across teams/workgroups to leverage Conway's Law (which can also just as easily lead to software components that don't make any engineering sense if people aren't conscious of the effect their organization has on their software's organization).