I believe consistency and orthogonality are tools of design, not the primary goal in design.
Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said, "OK, we'll do them both". So the language is too baroque for my taste.
Google is famous for making the tiniest changes to pixel locations based on the data it accrues through its tests. Google will always choose a spartan webpage that converts over a beautiful page that doesn't have the data to back it up.
It seems to be a law of design that for every advantage introduced through redesign, there is an accompanying unintended disadvantage.
You can converge a toaster and a refrigerator, but those things are probably not going to be pleasing to the user.
Up to a point, it is better to just let the snags [bugs] be there than to spend such time in design that there are none.
Orthogonality for orthogonality's sake is not something I'm keen on.
My site is a little unorthodox without being totally inaccessible.
In my opinion, no single design is apt to be optimal for everyone.
Constrained optimization is the art of compromise between conflicting objectives. This is what design is all about. To find fault with biological design - as Stephen Jay Gould regularly does - because it misses some idealized optimum is therefore gratuitous. Not knowing the objectives of the designer, Gould is in no position to say whether the designer has proposed a faulty compromise among those objectives.
Received wisdom is that if you spend time up front getting the design right, you avoid costs later. But the longer you spend getting the design right, the more your upfront costs are, and the longer it takes for the software to start earning.
You can prematurely optimize maintainability, flexibility, security, and robustness just like you can performance.
Language designers want to design the perfect language. They want to be able to say, 'My language is perfect. It can do everything.' But it's just plain impossible to design a perfect language, because there are two ways to look at a language. One way is by looking at what can be done with that language. The other is by looking at how we feel using that language-how we feel while programming.
We call the fates of the Titanic and the Concordia - as well as those of the space shuttles Challenger and Columbia - 'accidents.' Foreseeing such undesirable events is what engineers are expected to do. However, design trade-offs leave technological systems open to failings once predicted, but later forgotten.
