I have seen many programmers and senior programmers showing their prowess in implementing and justifying a design pattern implementation. Before doing so one should ask a very simple and honest question to self, “Do I fully understand it?” I am sure many of you, would say off course, what’s the big deal. Now look at your decision once more by answering the following questions:

1. Does your team, working with you also understand the pattern correctly? Are they comfortable with its implementation?
2. Would you be there till the project reaches its logical end or do you have at least one successor who would be there and understands the pattern correctly?
3. Does it require other members to follow a set of rules while coding?
4. Do you understand “What it solves” OR “How it solves”?
5. Are you thinking about scalability or maintainability?

Thoughts on Question 1

Most of the serious projects require a team of developers working together on different modules. If they do not understand the pattern, it is more likely, that you would encounter chaotic and unorganized codes. The common evils are repetition of codes which explains the lack of understanding the design pattern, code tweaking to override design pattern, hard coded lines, code spaghetti and more. Wow these codes could kill.

Thoughts on Question 2

Something that remains constant in software development is “Change”. It is inevitable and the requirement itself keeps changing. No doubt the design patterns are there to help, but when it requires any change, who’s going to do it? In case it falls in a wrong hand, it would shit all over your effort and logic.

Thoughts on Question 3

If your answer to this question is YES, then you must ensure you understand question one, and keep a constant vigil or do a knowledge sharing for your team to bring them on the same page, else the errors and problem can pretty quickly escalate making your module a piece of shit. If your answer is NO, then you need to worry about question two only.

Thoughts on Question 4

A big question! It is really easy to say what it solves, but knowing how it solves is entirely a different ball game. You need to think on what is the price you need to pay for implementing it, what are the other alternatives, is there a mix and match of patterns to suit your need, does it increases the complexity of the module or simplifies it, what is the cost of maintaining it, how frequently it is expected to change, what are the impact points etc. etc. I am sure it would make you crazy, at first it seemed to me as a simple question but later wow!

Thoughts on Question 5

You must read what other people think about scalablability. Damien Katz, in his post, writes about crappy programmers, boasting about concepts like enterprise, scalability and patterns without actually understanding it. Another hilarious and a bit “PG” post by Ted Dziuba, where he is really pissed off and frustrated with people talking about scalability without having a good knowledge of it. In sync, there is another post by Rajiv Popat where he talks about the best practices and people who seriously talk about such concepts but are not able to answer the simplest questions he asked.

Design patterns are not meant for scalability. It is about extension and maintenance. It should reduce the impact of change, help in decoupling the elements of module interacting with each other, reduce maintenance cost, provide extra room for extension.

Tuesday, January 13, 2009 5:17:12 AM (GMT Standard Time, UTC+00:00)    Comments [4] Trackback