Keith Braithwaite has been a Principal Consultant and Business Unit Leader at Zuhlke since 2006. He leads their Centre for Agile Practice in London, a group of engineers and consultants specialising in teaching, coaching and practising Agile development for clients in a wide range of industries around the world.
System-building projects which fail (which is many of them) do so more often because they build the wrong thing, not because they do a bad job of building the right thing. The Agile community has developed a range of techniques for making sense of system requirements and capturing them in artifacts that are familiar and understandable by business, useful to developers and informative to managers. The central concept is that of a "checked example" In This talk Keith will illustrate some of these techniques and artifacts by example and discuss the impact that they can have on users, developers and managers.
A previous attendee said: “[this session] is an excellent training exercise […] It emphasises the core principles of TDD more than anything else I’ve tried or read.” What if you really let the tests drive your development? What if you took the notion of TDD to its logical conclusion? What if you never wrote any code at all without the justification of a failing test? What would the resulting design look like? In this practical session attendees will work in pairs to develop real solutions to a simple programming problem using a very strict interpretation of the practice of TDD and see where that leads them. The experience and the solutions will be compared and discussed.
NB This is a hands-on session so please bring a laptop or be prepared to share. No specific software need be installed beforehand but please bring a laptop on which you can do some programming of some kind on.
Comprehensive automated unit testing, and the more extreme practices of Test first and Test Driven Development, have become very popular, but to what end? To date evidence of their effectiveness remains equivocal. Such evidence tends to focus on external quality attributes such as latent defect rates. This talk presents evidence that Java code which is accompanied by comprehensive automated unit tests has at least one internal design characteristic which is quantitatively different from that typical of code which does not: code with tests is more strongly biased towards simpler methods. This talk will explore the way that complexity is distributed through code and how TDD seems to affect that.