Code Kata Nr. 4

This week we got back to realistic programming. After last week’s fibo-emirp numbers (even if there were two almost perfect solutions) I found out that real life problems are somehow closer to the teams’ heart.

This week we had IBAN number checking as a kata (yeah, we are doing such exercises on purpose: I’m planning a great attack on World Bank 🙂 ). In order to check an IBAN number, one has to follow the steps below (note, I am using the following IBAN as test data: “IT60Q0123412345000000753XYZ”, taken from ):

  1. An IBAN number is an alphanumeric literal of at least five, at most thirty-four characters
  2. The alphanumeric string can only contain uppercase letters and digits
  3. The first two characters have to be LETTERS ( trough which we can identify the country of origin, IT60Q0123412345000000753XYZ, we have Italy)
  4. characters three and four have to be digits (IT60Q0123412345000000753XYZ, we’re doing great)
  5. the rest of the characters can be either letters or digits
  6. the first four alphanumeric characters have to be moved to the end of the string (Q0123412345000000753XYZIT60)
  7. all the letters have to be converted to numbers, following the formula:  A=10, B=11, C=12 … (260123412345000000753333435182960)
  8. as a last step the following computation has to be carried out; resulting number MODULO 97. If the value of the modulo is 1, then we have a valid IBAN. (*)

(*) A possible way of  modulo computation: divide the number into parts of (let’s say) eight digits. Take the modulo of this smaller number and put the result of the next pack of digits. Let us break this numerical string into five parts: 26012341, 23450000, 00753333, 43518296 and 0. The remainder of the division of 26012341 by 97 is 45. The remainder of the division of 4523450000 by 97 is 15. The remainder of the division of 1500753333 by 97 is 82. The remainder of the division of 8243518296 by 97 is 68. The remainder of the division of 680 by 97 is 1. []

If you’re curious of my solution, you can find it here:—IBAN-numbers

The kata is of two rounds, twenty-five minutes each. The exercise involves a constraint also, namely the one testcase one assert. This was needed because there were many cases when I saw testcases with 5-10 asserts. In my opinion that is not a very good practice.  Let’s consider the following situation: there is an algorithm of some kind that checks numbers against some criteria. Let’s say the algorithm is faulty and fails for 1, 11, 111 etc. If there is a single test case that contains a lot of asserts (positives and negatives alternatively) it’s gonna fail for one and the test runner will not go on. Which means that the method will not be checked for 11, 111 etc. So one tries to fix the algorithm for 1, and will not notice the pattern… I personally like to see how many test cases there were, how many of them passed, how many of them failed. I don’t like asserts that are not run at all. Comments on this are welcome.


XML operations – a refactoring dojo

The katas we’ve had lately made it clear that our teams need to be introduced to several refactoring concepts. I decided that I would take some not-that-good-of-quality code, and organize a dojo so we can refactor it. It’s not that easy to find bad code on the internet, and it’s not that easy to come up with a badly implemented project either. I wasted some days searching, but then BANG! I came across this site: Actually this is a very strange page. People post bad code there, someone comes along, refactors the whole thing, and posts it back. For free! Some people are either really committed to the community or just have a lot of free time. Anyway…

The code I’ve taken from that site (and made it even worse a bit) looks like:

 * Constraint: parses input strings in the form:
 * <xml><SvcRsData>a<![CDATA[<sender>John & Smith</sender>]]></SvcRsData></xml>
public class StringFunctions {

	private static String string = "";

	public StringFunctions(String string) {
		this.string = string;

	public static String doProcess(String string) {
		int index = string.indexOf("<SvcRsData>");
		if (index > 0) {
			int index1 = index + 11;
			int index2 = string.indexOf("</SvcRsData>");
			String s1 = string.substring(0, index1);
			String s2 = string.substring(index2);

			return doIt(new StringBuffer(s1).append(
					escapeCDataCharacters(string.substring(index1, index2)))
					.append(s2).toString(), false);

		return doIt(string, false);

	private static String escapeCDataCharacters(String string) {
		StringBuffer sb = new StringBuffer();
		int index = string.indexOf("<![CDATA[");
		String myString = string;
		while (index > 0) {
			int cIndex1 = index + 9;
			int cIndex2 = myString

							cIndex1, cIndex2), true));

			myString = myString
					.substring(cIndex2 + 3);
			index = myString
		return sb.append(

	private static String doIt(String s, boolean extendedCharacterEscape) {
		StringBuffer retval = new StringBuffer();
		short character;
		for (int i = 0; i < s.length(); i++) {
			character = (short) s.charAt(i);
			if (character > 128 ? true
					: extendedCharacterEscape ? (character == 34
							|| character == 38 || character == 60 || character == 62)
							: false) {
			} else {
				retval.append((char) character);
		return retval.toString();

So basically that’s it. We have a great dojo material here, it seems. There are no tests, the names are not that self-explanatory, methods are doing more things than they should be, and simply it’s messy. Refactoring, here we go. Tehre is a lot of work to do here, so let’s not waste time, start working! Adding test cases that cover the code is at least half an hour, another one, one and a half for refactoring.

I’ve ended up with something like this:; It might seem to be an overkill having four different classes plus one more for the tests, but anyway, this way I could encourage my audience writing small methods and classes (so they won’t be afraid of decomposing logics to different abstraction levels). Unfortunately, I did not take into account the time needed for adding test cases so we had a dojo of one hour only. Never mind, will finish it in a second part.

Code Kata nr. 3

So far we’ve had a credit card checking kata, another one on string manipulation, and now a tell-if-a-number-is-a-very-tricky-one. Its text, shortly is the following: given a number, return the FIBO-EMIRP number closest to it. Yeah, they actually are called FIBO-EMIRP. These numbers have the following properties:

  • they are prime numbers
  • the number’s reverse is also prime
  • the number is not palindrome (*)
  • the number is a fibonacci number (the fibonacci numbers: 1, 1, 2, 3, 5, 8, 13, 21 … Basically the i-th fibonacci number is given by the recursive formula f(i) = f(i-1) + f(i-2))

(*) It turns out that adding or removing this property does not have any effect on the final solution. Anyway, if you consider the kata too easy without it, just add the constraint; also, if you think it’s horribly hard, you can just ignore it.

Solving the kata (you can find it on my github page:—Fibo-Emirp-numbers) made it clear that two rounds of twenty minutes each would be enough. However, I did not take into account one important thing; the kata is not the best due to its character: a number has to be checked again and again and again against all the must-have properties. Putting together lots of different algorithms doesn’t make a good kata.

The goals of this kata were:

  • clean code with self-explanatory names
  • production code is added on red bar only refactoring is carried out on green bar only.

We also had an innovation this time, namely the introduction of infinitest (can be downloaded as an Eclipse plugin from Infinitest is a great automatic unit test running tool, that finds out which test cases are related to the source code being edited and runs them upon save. Such a way one can have a really fast feedback on the correctness of code. I’m looking forward to using it in our new project.

After the teams have solved the kata I’ve noticed a very important progress element: the guys were creating test cases step by step as described previously. Three weeks ago they were trying to write tests for the uppermost method, spending the whole time “in red”. Now, I’ve seen red and green bars alternatively which has made me glad 🙂

A lot of progress, go on folks!

Agilizing an organization, a first step

At the company I work for, we have several project roles, namely :

  • System engineers
  • Software engineers
  • Function test engineers
  • I&V

A story that happened to my team in the past has made clear that traditional ways of working need a bit of revision.

One day, adding a new feature was decided by our product management. It was quite a big feature, with a lot of coding, innovative solutions, automating parts of an existing system. In our company, the life-cycle of a feature starts at an implementation proposal-writing phase.  These proposals are actually sets of requirements, coming from our “customers” (we don’t have customers in the traditional meaning of the word, but anyway, it doesn’t really matter. Although I know that documenting requirements is not part of the agile framework, this document is really needed due to the lack of “real” customers). Our system engineer has come up with a proposal, that at some point, stated – the system shall somehow distinguish between different categories of objects.

The document was then handed over to design people. They started to find out how those objects should be distinguished. After several brainstormings, design discussions and debates it was decided that a best solution would be a new GUI element, namely an extended capability-table. However, swapping the old table with the new one took a lot f time. New methods were needed to be introduced to make the table compatible with the old implementation. This automatically generated a two weeks lead time, which also made the management a bit upset.

Finally, the implementation was ready, the increment was passed on to be function tested. Guess what happened; the new table was incompatible with our automated test cases, resulting in a (!)one month lead time. A whole team needed to be allocated to fix the broken test cases. Managers started crying, release date was postponed several times.

So we drew the conclusion that both design and function test should be somehow involved in requirements gathering. In a meeting of just one hour, we decided that:

  1. From time to time a little internal document review (thanks for the term, István) will be held; Designers can ask questions here, share opinions, give voice to doubts etc. Such a way everything written down in the document can be reconsidered before anything is made final. These meetings can generate prototyping and analysis tasks, in order to clear technical doubts.
  2. Component prototypes will be created by a couple or more designers. In order this to be successful system people will attend standup meetings. Short discussions will be held; system can answer “daily questions”
  3. There will be created a prioritized backlog for prototypes. The backlog will be administered by product owners (=system people), and will be reorganized in every two weeks.
  4. Function testers will also be involved in document elaboration. They will create automated test cases and stress tests for the above mentioned prototypes.
  5. Design people will be given the opportunity to take part in splitting work items into user stories.

The next implementation proposal will be written based on the action points above. We expect that more tricky details will be uncovered, making design and testing more fluent. We’ll see…

Code Kata Nr. 2

Since after the first Kata we’ve completed I received quite good feedback, we went on with a second one. I thought this time we’d start from something simple, having the possibility to complicate the exercise as much as possible. The basis of the Kata was again a little quiz from, namely string equations. However, I modified the syntax a little bit  to better fit for Java and avoid frustration from teams side.

So the exercise itself sounds like this:

  1. Given a string in the form ‘word1’ & ‘word2’ & ‘…’ == ‘wordn’ & ‘wordn+1’ & …, called a string equation. The two sides are equal if and only if the left side (without the apostrophes and &s) is an anagram for the right side
  2. Words might contain asterisks (yeah, yeah. I know… Words usually don’t contain such characters. But anyway, let’s just stick to the exercise) . Words that contain an odd number of asterisks are invalid ones, so they should be removed. Such a way they don’t count at the final anagram check. (I reached this point in a two-round kata, you can see my solution on my github page:—string-equations)
  3. Words that are palindrome (are the same read from the beginning and end) don’t count either.

We had an hour resolved for the Kata; I asked the guys to take extra cares of two things:

  • Self explanatory names (classes, methods, variables etc)
  • Correct usage of assert functions of JUnit

The first round took 20 minutes, all the pairs opted to work on the basic version of the kata. After the first round we had two complete solutions. At the discussion after the first round I was glad to hear the guys talking about writing much more unit tests then a week before.

In the next round, the two pairs having completed the first version started working on the extended kata, while the others tarted over the basic one (of course everyone had to delete their work so far -not actually delete, but unload it from eclipse).At the end we had again a complete solution, and a halfway-completed one (I told the pairs the main goal was to write clean and tested code, and not to just have a working implementation of the exercise. I see that they still think the only measure of these kata sessions is completely working code. Hope this will change over time. Till then I’ll tell them every time.)

What I saw after looking at the codes the guys wrote, I can say that this kata was even more successful than the first one. More test cases, better collaboration, correct usage of asserts (yeah we have that action point completed! Nicely done guys, we can move on to another one). However, classes and variables have had kind of strange names (I even saw a class named WTF :-)), like p1, p2, k, c etc. I also saw quite many long functions, hard-to-understand logic and overcomplicated algorithms. I definitely think that we are going to need a refactoring workshop, where we can look at several widespread antipatterns, and have them corrected.

Maybe I can arrange it it a week or two.

The super TDD pen

Today I have introduced my colleagues the “Super TDD Pen”. As I’ve mentioned earlier, most of these guys have never met agile, test first, scrum, kanban etc. before, so they need to practice and practice and practice even more. The most important thing before we start implementing business logic, is to catch up a bit with test driven development. In order this to happen, I take different approaches: organize code katas, discuss agile design values, send them articles to read, and the newest: The super TDD pen. It is nothing particular, just an ordinary marker we use to annotate tasks solved in TDD. I also updated the DoD (definition of done) to contain a reference to the red pen.

I considered it important to present the pen at the time only GUI mocks and prototyping tasks are present on the whiteboard. Of course, one can argue there is not much TDD involved in this phase of the project, but anyway; I hope they get a bit frustrated by the lack of red pluses, so they start writing code test first.

On the other hand, it will be a good marker how widespread TDD is in our project. I also plan to analyze task PostIts on a regular basis, so we can see the progress we make. I hope to see we are getting better at it, so we can place more emphasis on other important things too.

Code Kata Nr. 1

The credit card number checker kata

Some time ago, I was browsing, and found a very good exercise, namely “Credit Card Checker”. It’s not only nice because it is based on some ‘real-world-stuff’, but also because it has all the features a great TDD code kata needs.

Let’s see what the exercise is all about:

  1. Starting with the next to last digit and continuing with every other digit going back to   the beginning of the card, double the digit
  2. Sum all doubled and untouched digits in the number
  3. If that total is a multiple of 10, the number is valid

Some weeks ago me and my colleague have started working on the exercise above, and found out this would serve as a great kata (for beginners or a bit more advanced TDDers). In order to make it slightly harder, we also added the constraint that the card number’s digit groups must be separated with spaces (so some string operations are involved).

Here is what we came up with, after a kata of just one round (it could be improved, but as I mentioned, we had time for one round only) -the whole of source code can be found here, you can take a look, comments are welcome-:—credit-card-checker

Having solved this, I thought it would serve as a great first kata for my new project’s teams. It is a good start for several reasons:

  • it’s simple enough to be understood
  • it’s hard enough for TDD newbies to take them two or more rounds (anyway, extra constraints can be introduced for those progressing too fast.)
  • test cases are quite simple and straight-forward (just follow the steps above)
  • one can achieve 100% code coverage
  • confers the feeling of self-confidence upon successful completion

Although no one was able to finish the exercise entirely, there were some really good ideas, and we’ve got an almost-ready solution. We have had two rounds; the progress between those two rounds was a striking one. The second round’s solutions were waaaay better, every pair made significant progress.

One of the team members has mentioned after the first round, that he was under pressure because of the time limit (which was set to fifteen minutes). I told him it was important for progress measure, as we compare the first round’s solution to the second’s. I also told him, that his second solution would be far better than the first. And guess what, he proved me right. They (as we were working in pairs) managed to get way farther then they did at the first time. I hope I convinced him that time limit was necessary indeed…

In spite that we had no fully finished solution, I consider this kata really successful. The teams finally had a “do-it-yourself” session of TDD, and I think it was a good experience for all of us. Who knows, maybe we’ll look at this kata once more in some months and observe the progress made…