Development Topics

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...