| I have come to believe that we are dealing not with a domain specific problem but with the human condition itself. I call this my gradient theory. Consider human learning as an optimization in the mathematical sense. Note that humans are good at learning things along a gradient. Now note that this is not just about how the learning works but also how far we go. For example, if a human thinks it is too cold, they turn the knob not where they want the temperature to be but much farther up, and then when the desired temperature is reached, they turn it back. Or consider how you find a page in a book. You overshoot and then go back. Or how you choose the speed when driving. You go as fast as you feel comfortable, and you find that by overshooting and correcting. I think this is inherent in humans. Evolution made us this way. The downside is that humans are bad in environments where there is no clear limit or where you can't correct after overshooting, for example driving too fast and then having an accident, or substance abuse. Now take this thought and apply it to programming. If you find me a way to work with complexity, for example modularization, abstracting it away, etc., it will not lead to us writing a good version of the software we had before. It will lead us to writing larger software that will then again be at the limit of what we can do with the technology available. So far it is just a theory, but I can see in my software selection that all the programs that I consider good and simple in the sense that this manifesto describes, all of those are old programs that were written when the functionality they offer was the limit of what was achievable with technology back then. The reason they did not metastasize into something unwieldly is that a) they did but it was still comparatively small or b) they already contain all the features anyone could think of. Try comparing two programs of your choice that do essentially the same. You will find that if there is an old and a new one, the newer one will be bigger and slower and usually work in less environments and have less features. It also turns out that no two people have the same idea of what "simple" means. For me, with software, simple means it does all I really need it to do, and nothing else. Other people usually need it to do other things and they don't need some of the stuff I need. |
So basically Parkinson's law applied to complexity rather than time. I think it's definitely true. More complex software is (ideally) more versatile, handles more cases of the problem domain, and so there's competitive pressure to make software as complex as is feasible to solve as many problem as possible, and thus, provide as much value as possible. The ceiling is exactly as you said: what level of complexity is manageable given the other constraints that must be satisfied (performance, robustness, etc.)?
Edit: to be clear, I mean "essential complexity" above, not accidental complexity from poor designs. Being able to handle more essential complexity is a good thing.