Published Tick-the-Code Material
Happy Are The Software Engineers.. (article)
My first ever published article is called "Happy Are The Software Engineers.." and it appeared in Better Software magazine in December 2006. The article describes briefly how complete concentration can create the feeling of happiness especially if the task at hand is meaningful. I wanted to highlight that working for software quality is meaningful and with Tick-the-Code you can achieve complete concentration.
Simply put, happiness is Tick-the-Code.
Tick-the-Code Inspection: Theory and Practice (paper)
My first ever scientific paper is called "Tick-the-Code Inspection: Theory and Practice" and it appeared in the peer-reviewed publication of ASQ (American Society for Quality) called Software Quality Professional.
As the name says, the paper reveals all details of Tick-the-Code up to the 24 coding rules. At the moment this paper is the most comprehensive written source for information about Tick-the-Code.
Tick-the-Code Inspection: Empirical Evidence (on Effectiveness) (paper)
My second paper is called Tick-the-Code Inspection: Empirical Evidence (on Effectiveness). It was prepared for, and first presented at, Pacific Northwest Software Quality Conference 2007. The paper presents measurements taken in Tick-the-Code training courses so far (about 50 sessions with over 300 software professionals). The results are revealing. The main point of the paper is that software engineers could keep their software much simpler and avoid making many of the errors software projects are so notorious for.
In the Appendix of the paper, you'll find all the active rules of Tick-the-Code at the time of writing (summer 2007).
Tick-the-Code - traditionally novel technique in the fight against bugs (article)
Pirkanmaan Tietojenkäsittely-yhdistys (Pitky ry) published my article in their member magazine Pitkyn Piiri 1/2008. It is called "Tick-the-Code - uusvanha tekniikka taistelussa bugeja vastaan" and it is only available in Finnish.
Future Work
Tick-the-Code Inspection: The Book (book, working title)
Since 2006, I'm writing a book on Tick-the-Code to be the most comprehensive written source. I've written first drafts of all chapters, except one. I have received some review comments and acted on them. I have contacted a few publishers and received more comments (no approval yet). O'Reilly editor Andy Oram even mentions us in the Beautiful Code blog. Next, we'll need to get people excited about the concept and the book and then approach the publishers again.
Excerpt from the book
The excerpt changes weekly. Each excerpt is still a draft version and might change before ending in the book.
When a whole team has too much to do and they make the mistake of bypassing quality to keep the delivery schedule, they get caught in the Vicious Circle of Busyness. The team members see themselves as not having enough time, when in fact they have too much to do. There's a big difference. You can't create more time, but you can decide to finish less. As long as time is your problem, you're focusing on the wrong problem.
At first, just one team member produces rework-requiring code, his load becomes too much and the other team members pitch in. It is a good sign in a team that people help each other. But the power of busyness can be overwhelming if the team isn't equipped with a strong sense of quality-awareness and the right kinds of skills to produce good quality software. The Vicious Circle of Busyness is contagious.
The first-to-fall (the first to bypass quality) receives too much negative feedback to handle himself, his colleagues take over some of his planned tasks and being overloaded succumb to the call of busyness. They skip the scheduled code reviews as they are falling behind. Another victim falls into the Vicious Circle of Busyness, and soon another, and another. Before long, the whole team is affected. Because of their hasty decisions, their already tight schedule is filled with unplanned rework in addition to the original tasks. The harder they work, the more they produce, the less time they have, the more they need to work. That's the trap, and the team sees the only logical conclusion. They decide to produce less.
They can't lower the output too much or their manager would surely notice, but they need to do something. Decreasing the workload lowers the amount of negative feedback flowing into the team giving the team more time to work on the fewer features. They innovate only in ways to produce less without anybody noticing. In a sense, they go into hiding. They need to produce enough so their boss is not too unhappy, but not so much that they themselves are unhappy. Even the customer is less unhappy about the situation, but the important thing to notice here is that none of players are actually happy.
The team becomes a dull place where creativity and innovation are unknown. All the focus is on keeping the negative feedback at bay. The team has lost any ambitions they might have had in the past. They have no illusions of their place in the organization. They are there to fix their own errors, nothing else. Their inability to get out of the Vicious Circle of Busyness has driven them completely lifeless. The team spirit is broken. At the first opportunity, people start jumping ship and the team slowly disbands. All this because they went for schedule over quality.
The Vicious Circle of Busyness is an important concept in Chapter 3. "Root Causes". In this excerpt, we look at it with from team perspective. Individuals and whole organizations get caught up in the circle. The situation isn't as hopeless as it sounds. If your team is held hostage by the Vicious Circle of Busyness, i.e. you all have been ignoring quality in order to save time, Tick-the-Code can help you.