Lasse Koskela will be presenting a workshop on ‘Test Driven Development Applied’ at Agile India 2013. He works as a coach, trainer, consultant and programmer, spending his days helping clients and colleagues at Reaktor create successful software products.

Lasse is also the author of books ‘Practical TDD and Acceptance TDD for Java Developers’ and ‘Effective Unit Testing’.

He is one of the pioneers of the Finnish agile community and speaks frequently at international conferences. He recently spoke at Agile2012.

We interviewed Lasse recently and asked him several questions related to one of his favourite topics TDD (Test Driven Development).

What are the mindset changes required by the developer(s) and team members when adopting TDD?

That would likely depend on the developer but I’d say that most often the biggest change required in one’s mindset is to acknowledge that you don’t know everything.

The more experience a programmer has the more likely they are to think of themselves as being “good”. A little confidence can be a huge boon to productivity but too much confidence creates blind spots–we literally learn to not question our assumptions and end up repeating the same old solution even if it’s not a very good fit.

TDD, on the other hand, makes us state some of those assumptions–such as what would be a good design for this class–in such concrete terms that it’s difficult to ignore the awkwardness when the same old solution doesn’t quite fit. It doesn’t fit and you can feel it through the difficulty you’re having writing a test for that design. Sometimes, you look at your test and go, “that doesn’t make any sense–much easier would be to…” And you end up changing the design.

How does TDD help developers in improving the art of software craftsmanship?

The process of programming test-first where you begin by expressing your intent from an automated unit test’s perspective has an almost magical effect on the kind of code you write. It’s much harder to write the kind of monolithic code we’ve all come to hate so much because the process of test-code-refactor invites you to create small, composable classes with clear responsibilities.

What I’ve also found is that TDD tends to help programmers learn what object-oriented design really means. It’s not just about encapsulating your code into “classes” but it’s about putting cohesive behavior into those classes. I wouldn’t go as far as saying that TDD makes you write object-oriented code but it certainly helps. I would say, however, that the better you understand object-oriented design the more comfortable you’ll likely feel test-driving code.

TDD is often perceived as slow, how does one justify the costs and benefits of TDD?

I haven’t heard that particular comment in a while but there certainly are a lot of skeptics when it comes to TDD. I guess every significant programming technique will have some skeptics. Skepticism is not a bad thing per se. In reasonable amounts a little skepticism is a healthy thing to have. That’s why I don’t try to persuade people to believe that TDD is good for them. I might believe but that doesn’t matter much. What matters is whether they themselves have an aspiration for becoming better. If you have that aspiration, perhaps you’ll give TDD a try and see for yourself.

With that said, there has been quite a lot of research into TDD–much more than around most other agile engineering practices–and that research seems to support the notion that TDD is a viable method for developing software. Research done at IBM and Microsoft, for instance, has measured that TDD (compared to a test-last approach) reduced defect densities by 40-90% while the management estimated that it added 15-35% to the time to implement a feature. The management had also concluded that the cost was far outweighed by the time and cost savings created by the reduction of defects.

I will repeat, however, that I don’t want you to take my word for it–or the researchers’ for that matter (especially without reading the research papers yourself). Instead, I’d like people to accept the possibility that they may or may not experience those reported advantages. If they decide to give it a try, even better. If they don’t, I hope they’re giving some other new technique a try. The absolute worst outcome would be that we stagnate at the status quo and stop improving on our profession.

What will be the key take away for the workshop attendees?

For first-timers the key take away is absolutely the first-hand experience of test-driving code. For people who’ve already dipped their feet into the water, I would expect them to walk out with the realization that their style of programming test-first is just one of many–some of which they’ve seen applied in the workshop–and with a resolution to try something slightly different when they get back to work. That’s something I am hoping to take away myself, too!

Seats for Lasse’s workshop are limited so book soon to avoid disappointment: http://booking.agilefaqs.com

The third workshop we are covering is ‘Problem-Solving and Decision-Making in Software Development‘ by Linda Rising.

Linda is well known for her book ‘Fearless change Patterns for Introducing New Idea‘. It is cited for providing proven techniques, formulated as patterns, for implementing change in teams and organizations. She is well respected for her work on patterns and their application in the workplace.

Linda has delivered keynotes at many agile conferences and is an internationally well-known speaker. We are really looking forward to her keynote at Agile India 2013 and also this particular workshop.

This week we spent some time with Linda to get further information on her workshop and to discuss her keen interest in how the brain works.

What motivated you to do research in cognitive science?

When Mary Lynn and I were writing Fearless Change, one of our reviewers said that the reason the patterns worked was because they were based on influence strategies. I had heard of “influence” but didn’t realize it was a special area of study in “social” psychology – the psychology of group behavior. I started looking at the growing research in that field and it led to my current passion to follow advances in cognitive psychology. This field is making enormous headway and it has significant impact on the way we work. We need to pay attention.

Can you give us an example of the application of cognitive science in software development?

The most important news from this area is the disturbing finding that we are not rational thinkers. I have believed this nearly all my very long life so it is difficult for me to accept, even as I read the pretty clear evidence. Even smart people are not rational. And, it’s not that we are not rational some of the time. The message is that we struggle to apply rational approaches to any of our decisions. This turns our development process upside down. In the past we believed that customers were rational, fellow developers and testers were rational and that was how we communicated and made decisions. Seeing that we make decisions based on what is not only not rational but not available to us or anyone else, means that we can’t make assumptions about what others say or do.

What is the take away for the attendees from the workshop?

It’s impossible to summarize all of the advances in cognitive science but I will try to hand attendees a list of practical tips that they can apply when they return to work. These tips will help them be better thinkers, better problem-solvers, and better able to influence others. I also hope to encourage all of the participants to become interested in this area. I can provide references to help them get started.

Who is the target audience for the workshop?

Anyone who works in any organization and must solve problems, make decisions, or convince others will benefit.

Some past talks by Linda: http://web.lindarising.info/Live_.html

This is the second in the series of posts that we will be doing for workshops taking place at Agile India 2013. The next workshop we are focusing on is “Honing Technical Practices To Realize Sustainable Agility” by Venkat Subramaniam.

Venkat is founder of Agile Developer, Inc. and has trained and mentored thousands of software developers in the US, Canada, Europe, and Asia. He is also an award-winning author and has written several books including: ‘NET Gotchas’ and ‘Practices of an Agile Developer’ (winner of 2007 Jolt Productivity Award). He is a regular invited speaker at several international conferences.

We feel quite privileged to have him present several talks and also this workshop at Agile India 2013. He was one of the favorite speakers at Agile India 2012 based on the feedback we received. Also his video from Agile Inida 2012, was the most viewed video online.

While Venkat was traveling around the world attending conferences, we stole some of his time and asked him a few questions about his workshop.

What’s the take away for the attendees from the workshop?

Learning practical technical practices to sustain and succeed with agile development.

Agile development is really feedback driving development. Many organization and teams are really excited and focused on succeeding with agile development. They have aggressively adopted various management practices. While this is good and essential, it is not sufficient.

In addition to receiving feedback, the team has to respond quickly and effectively to the feedback received. In addition to right intentions, the team needs to have the technical ability to respond to change. It is hard to be agile if our code sucks. Having high quality code and quickly running automated tests, can help respond to those feedback and keep the response cycle running smooth.

Management practices (and the management support) are like the left wheels of a car. Technical practices (and the support from programmers and testers) are like the right wheels of a car. For a stable sustainable progress these wheels have to be aligned.

Programmers serious about improving their technical skills to support agile development on their projects or for the companies will benefit from this workshop. They will learn specific skills that have impact on their ability to respond to change and support their teams. They will learn how to create lightweight, evolutionary design, how to recognize and evaluate such design, to refactor code, write useful unit tests, create effective mocks, and how to practically create continuous integration feedback loops.

I invite programmers to bring their computers, roll up their sleeves, pair up with fellow practitioners, get their hands dirty with code and design, and hone their technical skills through this workshop. There is very little theory in this workshop, its all about learning by doing.

What are some of the main topics covered in the workshop?

• Agile development and sustainability
• Cost of technical practices
• Driving design using automated tests
• Evolutionary architecture
• How to make good use of mocks to aid unit testing?
• How and when to refactor code?
• Practicals of continuous integration

Are there specific tools or languages that you plan to focus on?

There is strong influence of programming languages and automated tools in this workshop. However, programmers have the flexibility to use the language they’re most comfortable with or relevant to their work. I can comfortably program in about 8 languages, which includes the main stream languages, so should be able to assist the programmers with specific questions and also compare and contrast approaches based on language influences.

Who’s the workshop intended for?

Programmers passionate and genuinely interested in improving their technical skills to support their organization’s agile development efforts.

Links to some talks/presentations by Venkat:

http://blog.agiledeveloper.com/2012/01/collections-of-presentation-videos.html