more and more complex (represented by the blue line). Cyclomatic complexity goes beyond 20 or 40 or even a 100. Source files become big – several are 100kB. Much time is spent merging the files before checking in, which is accepted as normal behavior. There is no time for refactoring. But they have all the time to suffer the consequence of bad habits.
The reality remains that the emphasis is functionality before quality. There is no real improvement. They will eventually give up one day and blame it all on iterative development – saying that it does not apply to them. The situation is not very different from tsunami-development. Still, the fact remains that they do have iterations – not the ideal, but it means that there is still hope.
4. eXcuse Programming
Everyone (hopefully) recognizes that the continuous model is an ideal place to be. But the reality is a fake iterative development approach. Here is a very important transition point for most project teams. They have tried something. There is some experience on the thrills and perils of iterative development. There is some recognition of the challenges.
Now there are two groups of people. The first group (which represents the majority) does what is most natural. They complain! It is no wonder that the most popular software development method today is XP. XP does not stand for eXtreme Programming. XP stands instead for eXcuse Programming. Yes, they come up with excuses, all sorts of excuses.
- There is no time to fix the bugs. They need to press for speed. The stakeholders and customers are pushing for a release.
- Testing is too difficult. Too much effort. Let’s reduce waste by doing tests just once later when the system is more ready.
- What you (actually referring to me as a coach/trainer) are saying is too academic, too idealistic, too abstract – it does not apply to them. Their situation is different.
- We have our own way of doing things, or so they say.
Of course, there are those who are so extreme in eXcuse programming that they do nothing. They remain at whatever state they are. To this large majority, Figure 3 is a great deception, a great hoax, which they are pulling off. They would eventually return back to tsunami development.
5. Or Biting the Bullet
The next group faces the reality of the situation. Figure 3 represents the reality of their attempts. When I showed Figure 3 to project teams, they light up. They recognize that either they win the competition or their competitors kill them. They recognize that there are no silver bullets in software development. They (stakeholders and development included) recognize the need to bite the bullet. It hurts. But it is necessary. Better now than later. I like to work with this group of people.
The point which hurts the most is time. Everyone has no time. But somehow they manage time to invest in stocks, talk about real estate, complain about politicians and their bosses. So, they indeed have time. The key is how to use it. Figure 4 shows time reserved to fix the bugs so the bug count goes to zero by the end of the iteration. The allocated time is signified by the flattening of the green curve at the end of an iteration. This flattening means that there is a principled refusal to add new features into the system until the current ones are really completed and accepted. The allocated time is also used to perform code improvements – some refactoring to prevent complexity from exploding. So, the blue line