Test Driven Development (TDD) is not just about the tests. Test Driven Development is also a design discipline. In fact, many TDD veterans prefer using the acronym to refer to Test Driven Design. So, how exactly does TDD improve design? TDD improves design by making the developer more aware of fundamental design principles. TDD does not force good design. TDD rewards for good design and punishes for bad design.
Through test-first development, design principles are moved from abstract, academic concepts to concrete needs.
Given the size and scope of Google’s code base, and speed of development, typical off-the-shelf continuous integration are unable to meet our needs. So, we decided to create a continuous integration and testing system as a centralized service on an unprecedented scale. When fully completed and operational, it will probably be the world’s largest continuous integration and testing system, running millions of tests every single day.
In this talk, we will report on our experience running such a program in an agile manner and will also describe the basic design and features of the CI system.
James Shore (coauthor of The Art of Agile Development) and Rob Myers of Agile Institute help you examine the role of metrics on Agile teams. We take a broad survey of metrics being used on Agile projects, both traditional and innovative, and look at the value and dangers to the success of the team. We look at how the simple act of measuring, itself, can be harmful, and when it is well-justified. Metrics at every level of the Agile organization will receive scrutiny: Measuring value, team performance, progress, quality, and even code design attributes will be taken into consideration.
In these turbulent times, businesses need people with specific characteristics and attitudes to enable survival and success. It turns out these attitudes and are very similar to what is needed on an Agile project team. This talk examines what attitudes and perspectives team members need to be successful on Agile projects, how these can contribute to overall organisational success and how to encourage and instil these attitudes in a team.
I’ve been on teams with way too little and (heresy) way too much testing. There have been lots of talks about how you should test more, but I’m going to dare to talk about when you should test less. Too much testing can lead to backlash, gridlock, morale problems, and poor velocity. Of course lack of testing can lead to bad design, gridlock, morale problems, and poor velocity. The level of testing a team can support depends on many factors including: team size, developer buy in, managerial approval, company size, IT support, and testing experience.
Priorities shifted twice a week. My favorite lightweight practices were all too heavy. Facebook thinks I might be a spammer. On November 5, the code became totally worthless. It was the best project I’ve been on!
Come and hear about a project that was too strange for normal, comfortable agile methods. I hope you can learn from my experience, and make sure you are bringing the right tools and processes to your next project. Focus on the principles of agile (communication, simplicity, feedback, courage) instead of the practices (CI, pairing, iterations, etc).
Many Java teams want a more modern language that preserves their investment in Java technology. This talk looks at Scala, a new JVM language that fixes many of the limitations of Java. I’ll show why Scala is an ideal “upgrade” language for most Java teams.
Using examples, we’ll see that Scala is statically-typed, yet it has a succinct and flexible syntax. Scala traits add mixin composition to Java’s object model. Scala fully supports functional programming, which is the best approach for robust concurrent applications. All these qualities improve our agility.
Traditional thinking holds that the more critical the application, the more tightly its development must be planned, staged, and controlled.
Regardless of your coaching experience, there are a wide variety of temptations you can fall into that affect the quality of your coaching. This presentation will describe: each of the 10 temptations, such as pride or impatience; the negative effects on you and/or your team for each temptation; and strategies to avoid falling into and overcoming each of the 10 temptations. There will discussion opportunties for people to learn from the more experienced coaches in the audience. Whether a new or experienced coach, this presentation will have information to improve your coaching.