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.
An Example Rule Introduced
There are 24 active rules in Tick-the-Code. Each one of them helps to locate either omissions, redundancies, ambiguities, inconsistencies or assumptions in the source code. Individual rule violations might seem minor, but when you let them accumulate long enough, you'll be in trouble.
Marked rule violations are called ticks. Try the following rule on your production-level code and see how many ticks you can find. Then analyze each tick and see if you can't improve the maintainability of your code.
The rule sample changes weekly, so in a mere 24 weeks of diligent visits, you can have yourself the complete set of Tick-the-Code rules. However, there is an easier way and you'll be rewarded with laminated rule cards to top it all up. Get trained! Contact Qualiteers if you want to know more.
"Code fragments must be unique."
Duplicate code leads to problems when the two (or more) sets of code are modified differently. Duplicate code increases the size of source and executable files. It is best to combine the duplicate code, for example, in a well-named routine.
Duplicate code, often copy-pasted code fragments, range from part of a line (a repeated
if expression) to blocks of code (a loop used in many places).
Tick-the-Code Inspection: The Book (book, working title)
Since 2006, there's a book on Tick-the-Code on the works. Currently the book project is on ice, as I study and gather more material and field experiences to include in the book. The book will be the most comprehensive written source on Tick-the-Code.
Excerpt from the book
The excerpt changes weekly. Each excerpt is still a draft version and might change before ending in the book.
Many software organizations struggle with quality, and even more seem to believe only in the power of testing. The logic is as follows: we have to test, because we have errors, and errors are unavoidable. There's only one hole in the logic. Most errors are avoidable. What's more, they are not just avoidable, they are feasibly avoidable, as well. It would make sense to get rid of most errors before testing, and it would even be economic to attempt. The actions in the organizations betray what the prevailing thinking today is. Regardless of what people say they think, they act like quality is made in testing. The testers get a broken software product to test, and they return it to be repaired. If you think about it, it makes no sense to first produce a broken product and then try to add quality and fix it. You can't add quality as the last ingredient. Quality needs to be sprinkled into the product in each and every phase of the way.
The organizations that invest mostly in testing staff and automated testing tools are committing themselves to the Fixing Fallacy. Fixing Fallacy is the wrongful hope that fixing actually improves the product. Each (correct) individual fix might improve the product in its part, but because we are talking about a complex system, the effect of the fixes isn't the same as the sum of them. Often the repercussions are negative. The idea that the software developers are not responsible for their mistakes, until somebody else finds them has a terrible effect on the dynamic between the developer and tester teams. Although the tester team's job description is mighty clear, it isn't an easy one. For all intents and purposes they will appear to be complaining to the developer team. The software developers see the testers as criticizing their achievements, and even delaying releases and progress unnecessarily. "We could be developing so much faster, if it wasn't for those testers!" you can almost hear the developers muttering to themselves. The developers are of course as wrong as the bus driver who one time in Tampere, Finland said out loud from behind the steering wheel, "this would be such a nice stretch to drive, if I didn't have to stop all the time." Of course the testers are trying to help the developers. Of course the developers are doing their best to not make broken software. Of course the bus driver was happy to pick up paying customers. But of course.
Unfortunately the human nature is what it is. The worst characteristics are often released under stress. Project work in software development can be very stressful. The developers might be just a little tempted to leave some code unchecked if there is a considerable chance that the test team will catch any oversights. Once the test team catches a few annoying careless errors, which the developer team duly repairs, a balance is born. The developer team starts to trust the test team and the test team has legitimate work to do, everything seems to be fine and dandy. The developers will confidently (and carelessly) keep producing code within the time limits mostly worrying about functionality, leaving the quality to the test team. Once the work gets busier, and it usually will, the developers start making more and more mistakes. The test team becomes overwhelmed and errors start reaching the customer. The management will be dumbfounded how such a nicely balanced cooperation suddenly starts to fail so disastrously.
The root cause behind problems with testing is that you cannot fix all errors, no matter how much you test. The developers will inadvertently make their software fail in ingenious ways that avoid detection. It is like an arms race between the developers and the testers. Einstein once said "there are only two things unlimited: the universe and human stupidity. Although about the universe I'm not sure." The principle applies in software too. There is no testing without holes, and errors in software are liquid that will find those holes and pass through them. The testers can bring in the big guns, the automated test environments and create test cases with impressive coverage figures, but they will still be out of luck in the end. The developers create such complicated code that the age of the universe in seconds isn't a large enough number to account for all permutations.
The testers usually lack direct access to the source code. The testers might not possess programming skills, and without the necessary skills to understand the source code, access to it wouldn't make any difference in the test results. Assuming the testers were skilled in programming, lack of time can still effectively forbid them from using source code to aid their testing. The testers are supposed to test that the customer won't see strange problems, and they need to do it quickly. To perform testing quickly you need to raise the abstraction level of testing. You can't test everything to the last detail in a large and complex system. It is just a lucky coincidence that the customer also happens to be an outsider to the software and doesn't usually have access to the source code. Harshly said, you have unqualified (from the point of view of software development, or better put, code construction) or uninformed outsiders trying to make a complex system foolproof by experimenting with it. I wouldn't bet on them succeeding any time soon. Yet many companies believe testing is the only way to quality.
They haven't considered, or simply ignored as too minor, the concerns about the responsibility gap between developers and testers, the insurmountable amount of permutations even an average-sized software system nowadays has, or the simple fact that rework costs. Software with errors is broken and needs to be reworked before releasing. Observing any (real) manufacturing plant would teach the software managers how terribly expensive it is to rework products on the production line. They would see that (real) manufacturing plants are doing all they can to minimize exceptions needing special care and handling. Yet in software, errors are no exceptions. They are an accepted evil.
Too much testing is a symptom dealt with in Chapter 2. "Symptoms". In Chapter 3. "Root Causes" we look at why the symptom shows up. Fallacies are not easy to cure, but they are easy to fall prey to. If you start with no testing at all, introducing testing is sure to bring more reliability to your delivery process. It is easy to think that getting more testing done is always going to be advantageous. There is, however, a point when adding more testing no longer adds any value. Many organizations have already reached this point of no return, but still they keep on adding testing.
The situation is even graver than just wasteful, because testing is no cure, it is just a way to find out that there is a symptom. Finding the cause is another matter and preventing the patient from getting sick in the first place can never happen through testing alone. Tick-the-Code is a vaccine that does prevent code from becoming complex and infested with bugs.