TDD Injection in legacy code

In a typical agile team, the team practicing TDD would write the test first, plug the business logic, make the test to pass and refactor the code (RED-GREEN-REFACTOR). This luxury may not be available for teams (legacy teams) who are new to agile methodology, and have a huge code base developed without TDD. This article explains some of the techniques that could help introducing TDD into legacy development teams.

TDD Injection in legacy systems
--------------------------------

1. First step is to, identify the code smells that you would like to attack. You can do this by running any of the freely available code smell/quality identification tool (Checkstyle, PMD,JCosmo, etc)

Once you have the list ready, prioritize the list for developers to refactor. For example, "reducing the lengthy methods" could be of priority than the "replacing the magic numbers with static code".

According to me, not all the code smells could be tackled by the junior developers (2-4 years of experience) alone. Some of the code smells need extensive object oriented programming and design skills. For example, replacing "inheritance by delegation", needs a careful thought. In such cases, the senior members of the team Or developers with good OOAD/P knowledge needs to be involved.

2. Next step is to, consider each of these high priority code smells within each iteration. Allocate time to fix them and in parallel, write the unit tests for those parts of the refactored code. Writing the Unit tests at this point of time and automating them ensures that, the refactored code has not broken the behavior of the system. I would like to call this as "TDD injection" technique.

The reason for "TDD Injection" technique is to not only introduce TDD in the middle of development, but specifically refactoring the legacy code.

3. Some teams specifically allocate”Cleanup iteration" just before each milestone release. This is really not a good way to do agile development, but if the project planning is poor Or in a dysfunctional team, the developers might rush delivering the code to customer without TDD. In such situations, one can reserve a day or two “or” may be an entire iteration (2 weeks, say) for clean up activities.

=== "Something is better than nothing".

Technical Debt

Here is a definition of technical debt got from KenMar's article

Technical Debt is simply deferred work not directly related to new functionality but necessary for the overall quality of the system . Examples of this include:

Some examples include:
1. Refactoring
2. Upgrading the database version
3. Upgrading any other software
4. Getting new plugins

Increasing the length of iteration for right reasons

We follow 2 week iterations and a good rhythm has been established. Recently one of the team member came and told me to increase the iteration length to 4 weeks. The reason he gave me was, "he is not getting enough time to test thoroughly". This is not the first time that I keep getting such requests, other reasons I have got so far are, "I want to deliver more features to give good visibility", "I am not getting enough time to understand requirements", etc.

One thing we have to understand is, increasing the iteration length will not solve the problems. One would end up in similar situation and problems but of a bigger size. We need to look at the root cause for the issues before increasing Or decreasing the length of iterations.

If a team is not getting enough time to understand requirements means there is inherently bigger issue with planning, estimation Or communication.

Key question in Scrum meetings: Impediments

I keep reviewing the scrum meetings of teams around me. One thing I have noticed so far is, the team enthusiastically answers the first 2 questions. When it comes to third question, which is on "impediments", either they say everything is okay Or won't bring up the problems.
There is a lot of value in answering the "roadblocks or impediments" question. The idea here is, if the team member says, he has some roadblocks the rest of the team members are supposed to jump in and help me in solving the problem. The reason being, until the road block persists this particular team member would become the bottleneck in the team reducing the throughput.

Some of the common roadblocks I have seen with teams is:

1. They have not understood the requirements properly
2. They have not understood the framework or a particular technology
3. Computer hitch
4. Network problems
5. Issue with one of the colleagues which is ultimately blocking his/her work.

Traffic Jam and Theory of constraints

While I was driving to work today, I noticed that there is a huge traffic jam. I noticed that the vehicles are moving slowly and intermittently. I was curious to know whatÂ’s happening and so peeped out of my car. I found that there is this huge public transport vehicle carrying tons of people with many hanging out, is not able to move beyond 20KM per hour. Since the width of the road is small, each time it stops at the bus stop to pickup people, everybody behind that vehicle has to stop and wait for it move.

The first thought I got was from theory of constraints. One of the principles in TOC is,

the system throughput is dependent on the bottleneck.

.
In the above case related to traffic jam, the public transport bus is the bottleneck and the speed and fate of the entire traffic on the road is dependent on how fast the bus moves.

Introduction to scrum: video by Ken Scwhabber

Ken Schwabber visits Google, and gives an introduction to Scrum. Here is the 1 hour video worth watching:

Pair Programming to avoid quick naps ?

Here is another article by Obie, a thoughtworker, who thinks that pair programming has helped him warding off, his "pairee" to stop unwanted works such as instant messaging, blogging, etc. He thinks this has resulted in improved productivity(including his own).

Pair programming has been one of the most controversial topics from the day I heard about XP, sometime during 2001-2002, and even till date it is the same. There are no numbers to prove the it works. But, nowadays I am finding tweaked version of pair programming. In some organizations they use pairing for a short while to bring junior developer upto speed on the technology/frameworks,etc. There is no rule for such pairing. But still they call it pair programming. Till date, I have personally not seen companies practicing pair programming(by the book), and the only place I have seen is on the pictures scattered around the web.

But I agree with Obie on the fact that, it restricts the usage of IMs, Phone calls, Blogging, News paper readings during office hours. Again there is a clause here, either the pairs would be productive or, unproductive(if they have good understanding between each other).

Is this really a good way to use pair programming ? I don't think so. If an organization uses pair programming to ward off unproductive usage of office hours, they are doing a big mistake. There is fundamentally a big flaw in managing projects.

Bringing Large Scale Change

Here is a good quote from Kent Beck on bringing large scale changes to the organizatio:

When I am in a situation where I want to change my environment, I try to
remember that I can only change myself. However, as soon as I change myself
I also change the way I relate to those around me, and that changes my
environment. That's how large-scale change starts, with one person choosing
to relate to the world differently and having that change spread.

Hesitation behind TDD

I have seen many people finding it difficult, even to start TDD. Key thing behind TDD is not testing but the design. Many programmers have no clue about OOAD Or OOP, then how can anybody expect them to do justice by practicing TDD ?

It is critical for the developers to be aware of OOAD before jumping to practice TDD.

Polarizing people

Today I got a chance to chat with Tim Snyder in Dallas office. He said something which was very powerful. He said

Don't be afraid to polarize people

Be brave to stand up and tell what you beleive as true.

People spend most of the time trying to be politically correct and not to offend people, and this leads to losing out on values.

Lean thinking next wave, are we really ready for it ?

I have been traveling from the last couple of days attending conference, meeting up with customers ,agile gurus, would-be agile managers. From this travel, what I see is that ,lean thinking is kind of catching up peoples' attention. Everybody talks about Muda("waste" in Japnese), they talk about Andan systems, etc. Are we really ready to bring lean into organization ? . If you ask me, No we are not. As per the statistics, barely 10% of the software organizations are practicing agile. I think if you have not mastered the art of agility, then moving directly to lean practices from traditional development would not only be difficult but might not succeed. Ask me why ? Lean thinking provides set of principles and values. Practices needs to be derived based on these fundamental principles and values. The team practicing waterfall model,has no clue about how to derive the practices. But an agile team has some clue about the practices that could reduce the waste. For ex: TDD, Refactoring,etc. This leads me to conclude that the team practicing agile methods have greater chances of implementing lean practices rather than the traditional development teams.

Decrypting "tools" in agile manifesto

As I am preparing presentations for the upcoming Valtech days conference, I am convinced that the tools are integral part of software development and it should be used thoughtfully.

The first value in agile manifesto says:

Individuals and interactions over processes and tools

.

As per the value mentioned above, the agile gurus' valued "individuals and interactions " more, than the processes and tools. They are not saying don't use tools Or processes, but use cautiously. The tools and processes should not drive the project but should complement them. Another evidence is from the book Goal, the highly efficient robots in the factory didn't increase the output. Similarly, having more number of tools in an organization or a project, does not make any difference to output, but using the tools effectively will inturn increase the throughput.

Taking the above evidence to the processes (Whether it is XP,Scrum,etc),they should not drive the project. They should be used to help the individuals to deliver the product to the customers.

When programmers get excited about agile methods, they get obsessed with it and start looking at these processes as magic wand to solve all their project related problems. Which is totally untrue, and most of the time, problems are due to people problems rather than process !!