Before clarity [software design]

Most software developers become preoccupied with the question of what makes good design at some point in their careers, usually after witnessing the effects of bad design first hand. At that point, we start to reflect. We go through a stage where we feel we know what good design is but can't really define it. Then we learn various design principles and rules of thumb that make it easier to judge what constitutes good design. But when these principles and rules conflict, we have to make trade-offs and decide what's most important in each situation. The blanket rule of thumb: Keep design as clear as possible. Regardless of the trade-offs, the most important thing was clarity. If a system uses a straightforward coding style - the classes and methods are well named and small enough to be clearly understood, and the system isn't littered with snarls of obscure code - then you can do just about anything. You can change the system with impunity, write tests for it, make adjustments, and add features, all with relative ease. So "clear design is good design" seemed like a reasonable rule of thumb because so much of what makes code impossible to maintain comes down to a lack of clarity. If you can understand your system, you can change it effectively.