As the common wisdom goes, the best way to fix a badly designed system is to design it right in the first place.
I know all to well just how much truth there is in that. The challenge is in telling when a design is bad in the first place, which is more difficult than it sounds. There are all sorts of metrics that can be captured during the development process, but none of them will yield any true indication of how good (or bad) the design actually is. Experience tends to be the only thing that is reliable, and even then it can often just be a “gut feeling” that something is wrong and incredibly difficult to identify what exactly that is. When a design is mediocre, it’s even harder since there is often an equal mix of good and bad making it all that more difficult to tell one way or another.
I’ve seen a lot of interesting things, a small handful of amazing things, quite a few questionable things, and even some amazingly horrifying things done in the name of design. I’ve had to dig deep into systems and their design to either work with them or fix them (usually fix them). Through that experience I have discovered that the design of a project can be summarized with one of two simple characteristics: one for good, the other for bad.