Ruminating on Design

Today is one of those days. I am designing a new software and in a reflective mood. I realized how many of our popular frameworks and software are simply stupid designs with no concerns for usability and aesthetics. Patterns are blindly followed. Anywhere you read blurbs about a software / framework having x or y pattern you should know you are headed for trouble.

Some popular buzzwords today are IoC (Dependency Injection), MVC, MVC2 etc. Ask many of those same designers who greedily incoroporate such patterns about use cases when those patterns shouldn’t be used and you will get a blank stare almost every time or a curt reply that there are none.

I am asking my potential employees when MVC shouldn’t be used and I haven’t yet got a decent reply. Can you?

I was reading about this new wonderful framework called Stripes. I like it. However it requires you to have “evil” getters and setters. How come people don’t realize that getters and setters are bad. How come people don’t realize that they aren’t really object oriented. In fact having getters and setters mostly indicates a design problem.

How come people don’t realize design isn’t about patterns or buzzwords. It is always a trade-off between possibilities. Only a good designer knows how to balance the consequences and make a proper choice, valid for a certain duration.

I was getting impatient by the minute when I ran around an old article from Alan Holub (may he live to ripe old age and with full health). He has spoken exactly about the issues I am talking about and has expressed it better than I could. Let me quote him.

Design, by nature, is a series of trade-offs. Every choice has a good and bad side, and you make your choice in the context of overall criteria defined by necessity. Good and bad are not absolutes, however. A good decision in one context might be bad in another.

If you don’t understand both sides of an issue, you cannot make an intelligent choice; in fact, if you don’t understand all the ramifications of your actions, you’re not designing at all. You’re stumbling in the dark. It’s not an accident that every chapter in the Gang of Four’s Design Patterns book includes a “Consequences” section that describes when and why using a pattern is inappropriate.

Stating that some language feature or common programming idiom (like accessors) has problems is not the same thing as saying you should never use them under any circumstances. And just because a feature or idiom is commonly used does not mean you should use it either. Uninformed programmers write many programs and simply being employed by Sun Microsystems or Microsoft does not magically improve someone’s programming or design abilities. The Java packages contain a lot of great code. But there are also parts of that code I’m sure the authors are embarrassed to admit they wrote.

By the same token, marketing or political incentives often push design idioms. Sometimes programmers make bad decisions, but companies want to promote what the technology can do, so they de-emphasize that the way in which you do it is less than ideal. They make the best of a bad situation. Consequently, you act irresponsibly when you adopt any programming practice simply because “that’s the way you’re supposed to do things.” Many failed Enterprise JavaBeans (EJB) projects prove this principle. EJB-based technology is great technology when used appropriately, but can literally bring down a company if used inappropriately.

My point is that you should not program blindly. You must understand the havoc a feature or idiom can wreak. In doing so, you’re in a much better position to decide whether you should use that feature or idiom. Your choices should be both informed and pragmatic.

I agree with him 110%.

Now that it is off my chest, let me go back to designing.