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 www.rubyquiz.com, 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: https://github.com/tamasgyorfi/Code-kata—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 www.rubyquiz.com, 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-: https://github.com/tamasgyorfi/Code-kata—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…

The power of words

The power of names actually…
I’ve come across this code the other day:

private boolean resultOfComparison;
public void setResultOfComparison(final boolean resultOfComparison) {
this.resultOfComparison = resultOfComparison;
}
public boolean getResultOfComparison() {
return this.resultOfComparison;
}

So, what is wrong with that code? Nothing in particular, it compiles and runs fine, so it’s perfect. Well, it is actually, until other people start using it and making assumptions about what resultOfComparison really means. (seems a little bit awkward to me to name a boolean variable resultOf… It’s either true or false. A result -for me- is something that you cannot guess with a chance of 1:2). Basically resultOfComparison was meant to keep track of whether a repository is up to date or not.

Since we as people are different we re thinking differently; We also like to be lazy a bit (not to browse through the code but make assumptions). It just happened in this case too. As different people had worked on the same feature, they imagined differently what resultOfComparison should have been in different situations. The following two pieces of code have been created:

//Class1
if (resultOfComparison) {
//do something
}
//Class2
if (!resultOfComparison) {
//do exactly the same thing
}

The first guy thought resultOfComparison must be false when the repository is up to date. The other one was sure that it has to be the other way around.

Yeah, not a big deal, one might say. Just correct one of the classes according to business logic and the glitch is solved. True. And easy to see indeed. But what if you have a system of 3000+ source files? Then you end up with a dysfunctional system, have to cancel a demo and spend a whole day in debugging.

The whole thing could have been avoided only by giving the variable a meaningful name, like repositoryUpToDate; so everyone could have seen how the particular thing have to behave runtime. The worst thing about this annoying bug was that all unit tests were in place. And all of them were green. They were based on the two different assumptions too…

I’ve refactored that name a bit, it became isInventoryUpToDate, so with a quick “find references” I was able to track all the issues down. Then all the broken conditions were trivial to fix. Kind of annoying bug; a whole day wasted. 😦