Development Topics

Lately I had a hard time to understand different notations used in UML 2.0 to represent relationship between classes in a class model. Though I have experiences in programming and designing, it did not help much. Therefore to enhance this knowledge I did some research on internet and also read a beautiful book on UML 2.0 by Martin Fowler . Indeed it helped me a lot and here goes some of my interpretation on Class modeling based on UML notations. UML 2.0 defines standard notations to indicate relationship between the classes. The class diagram is necessary while designing behavior of a component. Also helps a lot in TDD to scribble some design before start coding. The relationship between classes can be defined as below, Relationship that is defined at instance level , are of three type. Relation that is defined at instance level can be considered as a run-time relation. These relations are realized and contributed at run-time. Association: It defines the abstract form of a relat...

How do you measure that your code is maintainable? There is no such standard measure exists in IT industry that indicates that your code is maintainable. However there can be several disciplines which you can use to interpret maintainability of your code. One way of arriving to this is to identify different high priority code metrics and summarization of weightage of each of those metrics. For example look at the below calculation, Code Metrics Weightge in % Code coverage 50 Cyclomatic Complexity 20 Duplicates 10 Coupling 10 Large Class 5 Large Methods 5 Total 100      The above table illustrates the weightage derived from each metrics considered to calculate the maintainability index of software. The weightage can be calculated based on the target metrics you have defined for each item on the list. This calculation is quite interesting and c...

We always face interesting discussion on code matrices. I got a funny but very interesting understanding of the types of metrices and its prioritization that we always talk about.   I would spread code metrics into two categories,        Code matrices that can be identified with bare eyes by a developer.       Code matrices that cannot be identified with bare eyes by a developer.  Code matrices that can be identified with bare eyes are Unused types  Depth of inheritance Code comments etc. The above matrices can be identified by a developer while coding or refactoring and he can react on them immediately. For example, if he / she see an unused import he / she can delete it. He / she does not have to wait for a tool to detect it or to Google for a new tool to recognize this measure. Same applies for code comments, do not write comments if you find any irrelevant comment delete them right a...

TDD is an art of developing quality software. So, I call TDD is an art. A professional programmer dreams to write a program which is bug free and easy to understand. A program that is appreciated by the co-developers. TDD is something that can help you to do that and van be more than that; it creates a culture of developing good software. To become TDDer needs experience and a creative mind. You have to be tester and also a pragmatic programmer. It leverages the essence of real world programming, the clean code approach and beauty of refactoring.    Kent Beck in 2002 started this best practice and here I am trying to write some of my thoughts about it after experiencing this on my play projects, Three golden rules of TDD: 1.     You will start with a failing test. You are not supposed to write the production code until you have a failing test. 2.     You will write sufficient code to pass this failing test but not anything more ...

Lately I had a discussion with one of friend who works as a scrum master in an organization. He is starving to make the team agile for a long time. But he failed to do so. The main reason I can see is his approaches of developing the team. Sometime I feel that Agile is a bottom up process where as a scrum master you will need help from your sub ordinates to climb the ladder. But the human nature is too dramatic that you have to find a way to do that. That may not be so easy for all individuals. You have to understand the need of all members and also the way they like to work. A team can sustain without a scrum master but may not be the opposite always. Sometime we fail to decide. We do not enjoy what we do. No matter what, you have to accomplish your job by hook or by crook. The team empowerment is really necessary to lead a team towards agility. But most of the cases we see that we lead or push a team in such a situation that we lose the control and finally they fall into...