[Zev]

Rules was in quotes for a reason. Yes, there are a bunch of "rules" that are generally followed. Except when they aren't. Hot and cold colors, mixing font families and types up, etc.

A good designer will know when to break the "rules". Like a good coder will know when to hack something together, rather than obsessing on architecture and keeping code "clean". Its all perfectly logical. Except when they said "Fuck it, it will work better this way."

Massimo Vignelli had his grid, but David Carson threw it all out the window. Coder X might spend a few days writing his code in what he thinks is a clean, maintainable manner, while Coder Y might hack it together and worry about maintenance later. In both cases, both approaches can be right.

[phomer]

A designer breaking the rules will generally enhance their work. A coder violating an architecture will often just create long-term technical debt, at the expense of some short-term gain. That is, they'll get their piece done faster, but leave in its wake a nasty problem for someone else. Of course that only applies if the architecture is reasonable and its rules are correct from an engineering standpoint. In practice, many of the 'coding rules' are too brittle for the circumstances, thus making things worse, not better.

The difference is that one change is done purely for the improvement of the aesthetics, while the other is done because of some fundamental disagreement about the underlying engineering principles. One change is done irrationally because it "feels" right, while the other is a disagreement on the nature of the rules (or a lack of understanding of the purpose of the rules). But there are rules (whether or not they've been articulated).

Usually when programmers "hack" things, they cause a raft of other problems in their wake. As software development progresses from an art, to a science and onto engineering, hopefully the desire to hack at things will diminish. We can actually reliably build complex systems, but only when we choose to think about the right way to do it, rather than just react to our environment. Personally I don't think good programmers "hack". They build. It's very different.