Category Archives: Test Driven Development

TDDing, Pairing and overcoming common prejudices

Just read a wise posting from Mike Hill on Pairing and TDDing. Here are two points I want to cite. I hope I will raise your attention for more. If so, read the full article, it’s worth your time.

You can not go faster by shorting internal quality unless you are a noob.

Taking a step back and improving the internal quality is the best decision you can make – and you can make this decision tomorrow, today, now.

The hard part of programming is the thinking…, and pairing and TDDing both improve it.

This is true. During February we had a project struggling for about half a year. With one and a half tester we were able to automate the open-ended tests in just two weeks. On a previous customer one year earlier we had struggled with it for nearly one year. This came from the kickstart in the thinking before starting test automation – which I consider software development in my context.

Innovations for the New Software Engineering

During the last weekend I went on a IT professionals seminar. On Saturday evening there was a panel discussion, on which innovations are going to be expected from the IT world during the next years. While hearing the participants and some leaders from some bigger german companies, I got struck. The question that came made me think, what the biggest thing that could happen could be. Some time during the question, for cost-center vs. profit-center thinking it came to me, that the most obvious innovation seemed to be ignored. I decided to share my insight here as well:

Involvement of the customers and stakeholders in the Software Engineering

How do I get to this obvious innovation? It is no solution to gather requirements for several weeks and months, going back into the black-box of programming to build a system after a plan, that gets anyways blown up, deliver partial tested software just to find out, that the 20 percent of value for the actual user of the product are not included. If I want to get a new suit that looks nice, then I go the dress maker and participate and contribute to his work. Of course he can measure my lengths and go into his black-box of dress making and deliver the right dress for me. Really? No, there might be some try-on iterations wortwhile in order to get what I would like to have anyways.

I’m pretty much convinced: Only if customers and stakeholders understand this lesson I learned from Agile Software Development, will this contribute to the Software Enginnering. It is not enough to realize that there is something I have to specify and get something delivered afterwards. Like I have to give a dress maker my input of what I would like to have, like the color of the cloth he should use or the material of it, the Software customer has to participate in the definition of the software system he would like to be built.

Likewise if I go into a shop and ask for a suit, a good salesman will ask me questions in order to get to know, what style I prefer. Like I participate in this gathering by giving the right answers, in the software world it is the same. Software Engineers are not staring into the crystal ball to get to know what the system shall give as advantage to its users. (Though there is a family of methodologies named after the first of the two words, but this is not the intended meaning behind it.)

Likewise it is natural that there are some iterations necessary in order to get the right system. This is true for dress making like for Software Engineering. One has to look over the built product in order to see if it fits the needs. Due to high project lengths of software projects, there be a changed business situation, so that the product does not fit anymore. Maybe I was wrong in first place, when trying to guess what I would like to have – that’s because I as a customer even cannot take a look into my own crystal ball either.

Agile goes a step further. Agile asks the customer not only for participation but for commitment to the product that is being built. This is the case of for Iteration Demonstrations of the working Software each other week. This is the case during the iterations while working about complicated business rules of it. For the dress maker comparison there are no real complicated business rules behind the product he builds. This is the part where craft comes into play. The dress maker learned how to tie together some cloth to get a suit for me. The Agile toolkit does this for Software Engineering to some degree.

Last but not least I would like to denote that heavy customer and stakeholder involvement is not all of it. But at the current time it is the biggest first step to go in order to get real innovations out of Software Engineering. Like Pair Programming and Pair Testing while having the right input at the right time more than doubles the output. This is even true for real customer involvement.