I'm not sure I agree that complexity is always conserved. When I design systems, I often find that there's intrinsic complexity that I can't seem to escape, but that my initial designs are often quite poor and also include incidental complexity. If I'm thoughtful, and I learn the domain well enough, I sometimes find I can remove that incidental complexity. Alan Perlis had a couple of epigrams that echo this, I think.
> 31. Simplicity does not precede complexity, but follows it.
> 58. Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.
All that said, I've definitely seen cases where trying to insulate the user from the reality of what's happening behind the scenes often dramatically increases complexity. When it's done poorly, in increases complexity not only for the designer and programmer, but the user as well. One well-known example is the progress bar. After 30 years of lying to users about how long that file copy, download, or compile would take, many recent designs simply exclude it and include an animated spinner instead.
> 31. Simplicity does not precede complexity, but follows it.
> 58. Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.
All that said, I've definitely seen cases where trying to insulate the user from the reality of what's happening behind the scenes often dramatically increases complexity. When it's done poorly, in increases complexity not only for the designer and programmer, but the user as well. One well-known example is the progress bar. After 30 years of lying to users about how long that file copy, download, or compile would take, many recent designs simply exclude it and include an animated spinner instead.