Pattern Phobia

I guess everyone knows what patterns are today.But the question is "Are we using it when building systems?". Most of the time the answer is "No". It's very rare to find patterns from many codes i have seen in my work. Most of the times it's really hard to find patterns other than singleton.Sometimes it is possible to see some names with suffixes such as Factory,Adapter but they are never related to the behavior of factory or adapter. It's lacerating to find people with pattern expertise in any level with in the team.Why we don't use the patterns at all? Are we suffering with PatternPhobia? Why we are still reluctant to learn and use patterns? I can see wally of dilbert smiling at me and telling "Chasing Knowledge is a Fool's game asok".

Ok, In order to cure our Pattern phobia,it's good to know that what patterns can do for us.

1. The first best thing is, Patterns improves your design vocabulary.It's good to communicate the structure and collaborations of your objects with the help of patterns.
2. Patterns helps you to validate your design decisions.By the words of Erich gamma "Everything has a price in engineering.That's what i called Trade-offs". Patterns provide you the trade-offs when you use them without having to reinvent them.
3. Patterns helps you to design at higher level of abstraction so that it improves flexibility and reuse.
4. Patterns generate architectures . JUnit is yelling this at you whenever you use it.
5. Patterns lessen the entropy of your code - You have less challenges when you use patterns to predict the behavior of your code rather than using a hideous code.
6. Patterns can save lots of money. Patterns save lots of time when you use them and i hope you know time is money.
7. And Patterns enhances your design leadership.

Personally i am a pattern fanatic.Until this moment i have an ardent desire to learn new patterns,and to refine my existing pattern knowledge.Patterns helped me a lot to solve much more complex problems with ease.It gives you some "Aha" moments when you create something worthy.From now on, i guess your pattern phobia is reduced a little bit and i encourage and request everyone to use patterns when building systems.

But remember, Patterns are not silver bullet.Don't try to solve every problem with the use of patterns.If you have more usage of patterns, it means that you have more problems.

Software Architecture What and Why?

Whenever i was in a new development project,i have seen this.People show few diagrams with box and line notations and explain something about the architecture of the system that we are going to build. The ceremony of the architecture is short lived with a few diagrams and one or two useless sessions.Sometimes it is really frustrating that people explain the architecture of the technology we are going to use rather than the software architecture of our system.

If you try to find out what is software architecture You can get "n" number of definitions. Or else you may define as "Software architecture is a part of a activity in our process to fill the documents","Software architecture is the thing we consider when an entropy of our system is out of control".

Ok, Let's have a look at one authoritative definition from SEI people(Len Bass,Paul Clements,Rick Kazman). "The Software architecture of a program or a computing system is the structure or structures of the system which comprises the software elements, the externally visible properties of those elements and the relationship among them".The externally visible properties means what kind of service it exposes,the fault handling mechanisms, usage of shared resource etc...

To put it simply, Software architecture is the communication of explicit and documented design decisions to solve particular or set of business goals.It consists the software structures,collaborations and dynamics between them. Moreover it helps us to identify the non-functional requirements with the presence of functional requirements.Usually these non-functional requirements and denoted as the "ilities" of the system.These are the quality attributes such as performance, Usability, Configurability, Maintainability, Extensibility, Security, Availability, Scalability, Modularity, Interoperability, Testability and any other "ility" you are really interested when building systems.

And why software architecture is important?

1. It improves the communication between stakeholders.
2. Early design decisions.
3. Transferable abstractions of the system - Transferable abstractions means that you have derived some appropriate abstractions from your system. These can be transferable or reusable in some other contexts outside of the system or other system.

The best thing about software architecture is you can get it before building the system. What is best in it? We all know that business goals produces requirements and requirements produces software architecture.Imagine that if you give some identical requirements to two different persons will they build the same system. The answer is "No". Even if the systems built satisfy the same purposes there may be some difference between them in terms of structures, collaboration and dynamics.

So now you have the two systems built and how do you choose which one is better?. Based on some quality attributes and analysis, you have chosen one system is the best. But this is not the right choice in the production environment and you cannot create better systems based on trial and error by evaluating once they are built.

So if you have the software architecture you can evaluate it in the presence of prioritized scenarios and identify how well the architecture satisfies particular quality goals and find out how the quality goals interact.So that you can identify risks earlier rather than building the system and then identifying the risks later.

Happy architecting...

What is a good code?

So many times i wonder what is a good code? Some people say "Working code is a good code". I dont think so.If you have a chance to look at the working code it comprises lots of extraneous behaviors with it.Most of the time the working code seems to be obfuscating, monolithic spaghatti which violates minimalism.The working code is reluctant to know what is beautiful and always complacent to wear a ugly dress in the name of the work it does.

Some people say "Bug free code is a good code". Sometimes this seems to be valid.But bugs are born from infinite space and we always try to put them in a finite world.These temporal travellers can visit us any time if they come beyond from this finite space. A poorly tested code will produce problems in a later time.

Some people say "Flexible code is a good code". I hope everyone knows flexibility is an prime feature of a good code. Flexibility means that "we can change the code easily and use it in different contexts which are not originally intended". But overused flexibilty will lead to death.The more anticipated flexiblity will be a charming chaos with in the system.But flexibilty is great if it lies in variation points and evolution points of the system.

Some people say "The code which conforms to Simplicity is a good code".First things first. What is simplicity? Kent beck has introduced the notion of simplicity and simplicity means.

1. It should pass all the tests.
2. It should not contain duplicated code.
3. It should reveal intentions.
4. It should have smaller code base.

Still i strive for simplicity and flexibilty in my code. But i have a question in my mind.Have we ever tried building things using atoms?. Too much simplicity is just like hell.You cannot manage complexity by using too much simplicity.But Simplicity is great when it lies in the appropriate abstractions.

So what is a good code?. From my perspective a good code is highly cohesive code.If it is highly cohesive means it must support some appropriate abstraction and lightweight. If it is lightweight means it is less coupled.If it is less coupled means it has less dependencies.If it has less dependencies you can change it easily.So we can sum up a highly cohesive code comprising simpilcity and flexibilty is a good code so that you manage complexity and change.

Happy coding...

Code duplication, DRY and Refactoring

Recently i had a chance to look at some development code. The code base  contains lots of duplicated code. It's really disappointing even the experienced developers doing this bad practice.

       Code duplication is the result of copy paste reuse. Imagine that  you have duplicated a method in "n" number of places. After some time if you need to change that method you have to do it in "n" different places.It's really a nightmare for everyone who does the change.Code duplication increases the complexity of the code base and increases the maintenance activity. So please don't duplicate the code. Try to avoid it as much as you can. The experts say "code duplication is the fundamental programming sin and it is the number one code smell."

In this context it would be good to know one fundamental and well known principle when building systems. The DRY principle. Even though DRY is far grander than just code duplication it would be pretty useful to know and follow. DRY is an acronym of "Don't Repeat Yourself" . DRY principle states that "Every piece of knowledge must have unique, unambiguous and representation within the system. DRY is applicable for many things such as architecture, requirements, code, test, documentation etc when building systems.DRY helps us to reduce the coupling and improves the orthogonality of knowledge within the system.

If you are really interested in refactoring please apply the following refactorings to avoid code duplication.

1. Extract method - Use this when you have the same statements or expressions duplicated within the class.
2. Extract class - Use this when you have duplicated methods in different places and invoke the extracted class from different places.
3. Form Template method - Use this when you have the subclasses of methods do the same thing with the different algorithm.
4. Pull up field - Use this when you have the same field in different subclasses inheriting from the same parent.

So please don't duplicate the code. I wish this should be the last time i violate the DRY principle.

Why do we need to design?

In my short career i have worked in some simple projects as well as few million dollar projects.But in any of the projects i haven't seen any real design happened. Even if we did some design, it's just like preparing a big document with lots of unimportant and redundant details.Ok, coming back to the question, why do we need to design?

To put succinctly, Analysis is modelling of a problem, and Design is modelling of a solution. Analysis produces documents that customer can understand and design produces documents that programmer's can understand.

The primary need for design is, identifying the important issues early in the development.If you have identified potential issues early,it's easy to concentrate on those issues and thus avoid many risks later.The next best thing that design provides us is, it improves communication between the programmers and even with the customers.If you have a good design in hand, it's really easy to communicate your approach towards solving the problem.Ultimately, design helps us to change the software easily.It helps us to identify where to make changes to provide flexibility when the product is evloving.

Happy designing...

The ordeals of the maintenance programmer

I'm a software engineer by profession. Every morning i start from my home as the one who has no fear and very happy.But when i entered into my office and sit in front of my workstation i turned as a coward, cursed idiot who doesn't know what to do. Don't get panic as i am.

I have to do maintenance programming.

If you look at the system we have developed, it's really easy to understand there is complete absence of overall design leadership.The system we created does not reflect any vision or worthy goals.Here is the simple description about how we build systems. Create a few modules, write a 'n' number of classes.Name it anything we like.keep the logic in as many places as we can. Use interminable sequences of delegation. Make the code as ultimate "heavyweight" champion. Don't worry about the cohesion and coupling. keep the methods which has the reputation of longer than the great wall of china.Make the method names should not convey the meaning directly. Never write the code which can defend itself. Don't write unit tests. Don't check the code coverage to identify what are the dead code. Forget about flexibility, simplicity, clarity, maintainability and robustness. Never document anything. Always believe that the maintenance programmer is the god of programming who can solve all the puzzles created through the code. Ultimately never learn anything and don't mentor the people.Feel proud about that our knowledge is a "legacy" which comprised of all obsolete techniques and always proclaim that these are the best haphazard and expedient means of building systems.

Anyway i have to live with this.Me the programmer turned as a fire-fighter.Most of the time i feel myself as an idiotic Indiana Jones who chases the trivial treasure to fix  the bug.At the end of the day, if the work what i have done is not satisfying, i have to say to myself "Man you are a poor guy"