Skip to main content

Posts

The philosophy behind TDD

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

Me and Myself

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