TDD exercise for beginners

Two years ago I posted about this excellent site that contains various TDD problems that can be used by beginners to practice their TDD skills.
Over the last couple of days at the TDD mailing list there’s a thread in which people are putting links to all sorts of great resources for such exercises so I thought to put them all in one places for future reference

1. Http://nimblepros.com/resources – a site containing 11 code katas. I actually participated in a testing dojo that used the Gilded Rose Refactoring kata and it was great
2. http://stackoverflow.com/questions/2443697/tdd-exercise-ideas -  a thread discussing the same subject with several problems for TDD.
3. http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue – another (the original?) Kata catalogue. contains all the classics and then some
4. Roy Osherove blog contains two katas the first has variants in almost every language out there, and the second is a little more advanced aimed to teach interaction testing
5. http://cyber-dojo.com/ – when pushing the setup button you get a nice list of various problems.
6. http://coderetreat.org/gol – the classical Conway’s game of life used in Code Retreats

If you know of more sites and resources please write them down at the comments below

Read more »

Posted in: Agile practices,TDD,Unit Tests

Agile Research

I was lucky to have the chance to participate in the XP2012 conference which was held last month at Malmo Sweden. One thing that makes this conference special is that the conference is organized in a joint effort with universities. The basic idea (which is great) is to bring together practitioners from the industry along with academicals representatives in order to combine theoretical knowledge with real life experience. and make both share their knowledge.
The thing that did strike me weird however was that all the professors and PHD students I met, came from Exact Science departments, that is all of them were majoring/researching in some field related to computer science, software engineering or something similar.
Why is that weird you might ask. Well it was weird to me because most the things worth studying in agile are not technical in nature, they relate to human behavior, interactions team dynamics and general communications. I would expect that in order for these studies to be useful, they should be assisted by some people specializing in this kind of research. I would expect such research to be done in collaboration with phycology departments with business school with behavior specialist and even social experts. Computer science researchers (for most) simply don’t posses enough background to actually conduct this kind of research.
For example:
I attended one of the session which introduced such the following study:

Impact of Test Design Technique Knowledge on Test Driven Development: a controlled experiment

as the name suggests the goal of the study is to judge if concrete background of testing theory will change how TDD is practiced. Now don’t get me wrong, the assumption checked is very interesting and the experiment was done according to proper standards. However there was at least one little problem. The subject of the experiment were under graduate student undergoing a programming course as part of their studies.
Which raises the following question:
Under what conditions would someone consider a group of students to be a fair representatives of the general developer community?
Are we seriously going to take undergraduate students (which at most had a course about TDD and most likely just an intro session of 2 hours) and treat anything that might happen to them as useful evidence applicable to the general group of developers?
I think this is probably a very big mistake.
so how does this example relates?
During the conference I heard a nice story about some behavior studies conducted in the US sometime in the 70’s. It appears that those studies which later became the foundation of the field, suffered from a similar symptom. Most of them were done on subjects which were mainly young adult white males in the age range of 20-30. Naturally it was later found out that conclusions drawn from that research group were not very applicable when facing the wider general population and they were a little bias in their finding.
Are we sure its wise to repeat that mistake yet again?

Read more »

Posted in: Research

The Mistake Programmers makes with Requirements

One of the more common complained I often hear programmers make is that they don’t not get good enough requirements, and even when they get them its many time too late and more often than not they significantly changes along the way.
(and by change I don’t mean getting new requirements all the time which also happens, but to the same requirement starting as one thing and then ending as something different)
at the end of such a complaint there is always the assumption, which sometimes is said explicitly and sometimes not, that if “they” could write proper requirements all our problem will be solved.

Perfect requirements are a Myth

in order to understand this statement one must think what is the purpose of a requirement. that is why do we use this mechanism. and the goal is actually quite simple. we need to get a need which usually sit at the user/customer head and be able to move it into the programmer head in such a way that the programmer will have full and complete understanding of what’s need to be done.
unfortunately the mean to pass ideas from one head to another without any lose of meaning does not exists in our world (yet), and therefore no matter how hard we try we can only do better and not perfect.

How are we doing?

Apparently not great. programmers still complain that they need to get better requirements. However I feel that we got it wrong. We have been trying for the last decade or so to make things better. Good and smart people have come up with ways to improve requirements writing and invented better way for formalization for example Tom Gilb points out that

“Requirements, the root to failed projects.”

and has some great ideas on how we can improve on that. but at the end this is in my opinion he wrong way to go.

if you can't beat them, join them

We programmers must accept the fact that understanding the business is our responsibility. Expecting others to explain things to us is quite a childish approach. At the end it is us who knows best how to gather the needed knowledge in such a way that we can understand it we fully understand things, therefore it is we that need to go out and follow these ways and reach the needed understanding. Fleshing out the requirements to a point in which we can implement them is our responsibility.
Yes there are people who can help us along the way, and yes some of them belongs to the product side which traditionally is in charge of writing requirements. But no its not their responsibility to explain it to us. They are in charge of picking out the good features, they are in charge of finding the best ways the product can grow and serve the customer. when they do its our job to understand what they want and then implement it to the best of our ability.
It is the programmer job to understand the requirement.

Read more »

Posted in: Agile practices. Random Thoughts

What I’ll be doing at Agile Practitioners 2012

I’ve been quiet for some time now. mainly because I was very busy in making Agile Practitioners 2012 event happen. It was and still is a lot of work but most of it is fun and I do hope that all the people coming will enjoy it.
over the last couple of weeks I’ve been asked a couple of times what would be good session to go to. basically I don’t know all of the speakers are good and while I haven't heard all of them speaking those I did had excellent sessions. Its really hard to choose from them.
But out of all of them here's a list of those I’m planning to to attend.
of the three available workshops (Gojko, David and Corey) ill attend the Improving your TDD. ITs not often that I have the chance to hear about my main passion from leaders of the industry and this rare opportunity is too much for me to pass. (I do hope I’ll have the chance to peek in the two others though)
On the second day naturally ill hear the two main keynotes.
but other then that I think ill go with the following:
1) Agile Meets the Falafel-Land: Culture Clash or Common Cause?
While at the end I do believe people are people, the notion about us being a little different then the rest does appeal to me. and it would be great to hear how other people deal with things that are unique to our culture.
2) 10 Phrases That Can Derail an Agile Project
Being a close friend of Gil I had a couple of chances to hear him and I enjoyed it every time.Also I have a feeling that this session will have a few practical lessons for me to learn. Gil is really bringing some Product Owner wisdom and knowledge that I find very useful in my line of business.
3) Design For Testeblity is a Fraud
while I already heard this session before. I think it will be a little hard for me to skip this one.
4) Weaning a Legacy Platform From Offshore QA
I Find offshoring to be a very weird concept. one of those things that sounds like a very good idea until you actually try to do it. Too many times I’ve seen it fail. While I respect the fact that in some contexts that may be good idea. I still would like to be prepared to the day when someone asks me to help bring work back.
5) The Mythical Man-Month –
An Agile Perspective
Hearing about Brooks is always a good idea. Besides this is my first chance to hear Ohad, something I’ve been wanting to do for quite some time now.

So what session you are planning on going to? if you still haven’t decided that’s ok. But if you haven’t already registered Shame on you, quickly before anyone notice go here and register. There’s still enough time and a few places left

Read more »

Posted in: Conferences

Agile Practitioner IL – Fourth Meeting

I had much fun at yesterday meeting. I really liked the amount of questions and interest people showed. While they didn’t make my life easy, I really enjoyed the conversation and discussion.
for those who missed here are the slides

Agile in unfriendly territories

View more presentations from liorf

Hope to see you all again net month and of course at the Agile Practitioners 2012 conference

Read more »

Posted in: Agile Practitioners IL,Scrum