Israel Dot NET Developers User Group (IDNDUG)

Next week I’ll be talking at the IDNDUG group meeting about test automation. its going to be quite a long session (about 2 – 2.5 hours) and I will try cover several aspects of test first approaches as they developed over the past few years.
While the session will not be completely technical and will I include some general background, I do intend to dive a little deeper then your regular “Introduction is TDD” session. so if you are planning to come do bring your laptop, we might find some use for it.
for more details and for registration go here

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: ATDD,AUT,Events,TDD

The Role of Management

One of the talk I really enjoyed at XP2012 was: The Manager's Dilemma by Ola Sundin. In this talk Ola tried to answer a simple question that always rises when an organization is starting to adopt Scrum: What is the management role?

Manager as the developers of the Organization

It was lighting talk (15 minutes), so there was not a lot of content there, but there was a single excellent idea. The managers are the people which are responsible for making the organization better.
while the team, the SM & the PO  are in charge of developing a product making it better. Managers are there in order to improve the organization in order for it to become more valuable to its customers (share holders).
Using this basic idea Ola showed how he managed to bring all the managers into a single “scrum” team and use the basic scrum framework to manage their work. The had a daily they had a nice visible board, they created their own backlog of items etc.
And it all started by making the managers do a Gemba walk each day. That is the managers made themselves truly available for the team, by walking around and communicating to people each day.
The rest of the details can be found in his slides
Remember:

Managers are people too, Ola Sundin, XP2012 Malmo.

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: Agile Management

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