(note: I can compress some (but not all) of these talks to shorter times if necessary. Check with me.)
Computer science is built on a shaky tower of abstractions, but we’ve been distracted by other things until we believe it is reality. This talk teases apart some of the tangled abstractions that have become so common they are invisible yet impact important decisions. I cover languages, tools, platforms, and burrow all the way down to fundamental concepts. This wide-ranging keynote answers these questions and more:
Oh, and some jokes too.
We have all figured out that Agility works, but have you ever investigated why it works so well? This keynote investigates some Agile practices and explains why they work (when it seems like they wouldn’t). Disparate stuff like cell phones, brain theory, toys, and other stuff appear when least expected. And, as an added bonus, this talk includes tons of RPS strategies (and explains why you need them).
Donald Rumsfeld was right: it’s the unknown unknowns that are the real killers in software development. Design decisions made too early are just speculations without facts. But you must have architecture in place before you can do anything. This session talks about the tension between architecture & design in agile projects, discussing two key elements of emergent design (utilizing the last responsible moment and harvesting idiomatic patterns) and how to de-brittlize your architecture, so that you can play nicely with others.. This talk includes both proactive (test-driven development) and reactive (refactoring, metrics, visualizations, tests) approaches to discovering design, and discusses the use of custom attributes, DSLs, and other techniques for utilizing them. The goal of this talk is to provide nomenclature, strategies, and techniques for allowing design to emerge from projects as they proceed, keeping your code in sync with the problem domain.
Most of the time when people talk about agile software development, they talk about project and planning practices but never mention actual hands-on-keys, as if development where an afterthought when writing software. This talk drills into the real details of how to do agile engineering. I discuss best practices like continuous integration, pair programming, how developers should interact with story cards, how to handle enterprise concerns like integration with other software packages, and a slew of other topics related to agile software development.
ThoughtWorks’ Technical Advisory Board creates a “technolgy radar” 3 or 4 times a year, a working document that helps the company make decisions about what technologies are interesting and where we will spend our time. This is a useful exercise both for you and your company. This session describes the radar visualization, how to create litmus tests for technologies, and the process of building a radar. You need two radars. As an individual, a technology radar helps guide your career decisions and focus your precious R&D time. For your company, creating a radar helps you document your technology decisions in a standard format, evaluate technology decisions in an actionable way, and create cross-silo discussions about suitable technology choices. Attendees will leave with tools that enhance your filtering mechanisms for new technology and help you (and your organization) develop a cogent strategy to make good choices.
This session describes the current thinking about emergent design, discovering design in code. The hazard of Big Design Up Front in software is that you don’t yet know what you don’t know, and design decisions made too early are just speculations without facts. Emergent design techniques allow you to wait until the last responsible moment to make design decisions. This talk covers four areas: emergent design enablers, battling things that make emergent design hard, finding idiomatic patterns, and how to leverage the patterns you find. It includes both proactive (test-driven development) and reactive (refactoring, metrics, visualizations, tests) approaches to discovering design, and discusses the use of custom attributes, DSLs, and other techniques for utilizing them. The goal of this talk is to provide nomenclature, strategies, and techniques for allowing design to emerge from projects as they proceed, keeping your code in sync with the problem domain.
Domain Specific Languages seem like a cool idea, but where’s the payoff? This talk provides an overview of how to build both internal and external DSLs (including the state of the art tools), stopping along the way to show how this is practical to your day job. This talk defines of DSLs (Domain Specific Languages), distinguishes the types of DSLS (internal and external), and shows examples of building DSLs of several kinds. It shows how to utilize DSLs for externalizing configuration (which you’re already doing, whether you realize it or not), how to make your code readable to humans, how DSLs make developer tools better (and how to use DSL techniques to build your own tools), and how DSLs can provide your users unprecedented flexibility and power, by building DSLs customized to their job. This talk provides a good foundation for the subject if you’ve never seen anything about it, but keeps the focus on practical goals.
Learning the syntax of a new language is easy, but learning to think under a different paradigm is hard. This session helps you transition from a Java writing imperative programmer to a functional programmer, using Java, Clojure and Scala for examples. This session takes common topics from imperative languages and looks at alternative ways of solving those problems in functional languages. As a Java developer, you know how to achieve code-reuse via mechanisms like inheritance and polymorphism. Code reuse is possible in functional languages as well, using high-order functions, composition, and multi-methods. I take a variety of common practices in OOP languages and show the corresponding mechanisms in functional languages. Expect your mind to be bent, but you’ll leave with a much better understanding of both the syntax and semantics of functional languages.
Creating and delivering technical presentations is not just the realm of conference speakers anymore. Let’s face it: if you have to give a technical presentation and it’s boring, you’re not going to make much of an impact. However, if you can make it entertaining and informative, you sell your ideas much better. This session takes a different approach to how to build presentations, by providing patterns and anti-patterns you can use to make sure you’re getting the most leverage from your presentations. Don’t take a knife to a gunfight! The ability to create compelling presentations that explain your point is one of the things that keeps your job from disappearing.
While others have been debating whether Rails can scale to enterprise levels, we’ve been demonstrating it. ThoughtWorks is running one of the largest Rails projects in the world, for an “Enterprise”. This session discusses tactics, techniques, best practices, and other things we’ve learned from scaling rails development using agile techniques and tools. We discuss infrastructure, testing, messaging, optimization, performance, and the results of lots of lessons learned, including killer rock-scissors-paper tricks to help get you out of babysitting the view tests!
At ThoughtWorks, we’re big fans of evolutionary architecture and emergent design, which allows great technological and business flexibility. But like many accelerants, it isn’t entirely free. This talk explores decisions made and consequences (both positive and negative) from a real world project that has used these techniques aggressively for 4 years.
Most developers thing that Test-driven development (TDD) is about testing, but testing is only a small benefit from using TDD techniques. This session demonstrates how stringent TDD improves the structure of your code. I discuss TDD as a technique for vetting consumer calls, using mock objects to understand complex interactions between collaborators, and some discussions of improved code metrics yielded by TDD. This session shows that TDD is much more than testing: it fundamentally makes your code better at multiple levels.
Judicious use of metrics improves the quality of your code. But interpreting metrics presents a challenge. You have a list of numbers for a project - what does it mean? And what does it tell me about the health of the project overall? This sessions shows how to produce visualizations for software metrics, making them easier to understand and more valuable. It covers metrics at the individual method level all the way up to the overall architecture of the application. This isn’t just a talk about how some tools produce visualizations: this session shows you how to generate your own visualizations, allowing you to customize it to the level in information density that shows real value on your project. I show how to produce projected graphs from dependencies, heat-maps for cyclomatic complexity and code coverage, using XSLT to extract visual information from XML configuration documents, and others. Metrics can’t help you if you can’t understand them. By creating visualizations, it helps leverage metrics to make your code better.
Getting software released to users is often a painful, risky, and time-consuming process. This workshop sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and operations, delivery teams can get changes released in a matter of hours–sometimes even minutes–no matter what the size of a project or the complexity of its code base. The workshop materials are derived from the best selling book Continuous Delivery and creating in collaboration with the authors and other of my ThoughtWorks colleagues.
In this workshop I move from release back through testing to development practices, analyzing at each stage how to improve collaboration and increase feedback so as to make the delivery process as fast and efficient as possible. At the heart of the workshop is a pattern called the deployment pipeline, which involves the creation of a living system that models your organization’s value stream for delivering software. I spend the first half of the workshop introducing this pattern, and discussing how to incrementally automate the build, test and deployment process, culminating in continuous deployment.
In the second half of the workshop, I introduce agile infrastructure, including the use of Puppet to automate the management of testing and production environments. We discuss automating data management, including migrations. Development practices that enable incremental development and delivery will be covered at length, including a discussion of why branching is inimical to continuous delivery, and how practices such as branch by abstraction and componentization provide superior alternatives that enable large and distributed teams to deliver incrementally.
Reading and hearing about agile practices is one thing, but actually doing it is completely different. This workshop puts you to work in an agile fashion, applying agile development practices. During this workshop, we’re going to take a problem and iteratively develop the solution, using test-driven development, pair programming, retrospectives, pair rotation, and other agile development techniques. To make it interesting, we’re going to split the room into 2 continents and work through the issues faced by real distributed agile teams. We work through several 20-minute iterations during the workshop, giving you a hands-on feel for real agile development. If you have a laptop, bring it, but only half the class needs one, so if you don’t have a laptop, don’t let it discourage you. Come see what it’s like to work on a real distributed agile project, even if it’s only for 3 hours.
The Productive Programmer consists of two parts: mechanics & practice. In the mechanics section, I identify 4 principles of productivity: acceleration, focus, automation, and canonicality. This session defines the principles and describes their use, but the primary focus of this workshop is real-world examples of how you can use these principles to make yourself a more productive programmer. The second part of this workshop covers 10 ways to improve your code, derived from the practices section. This workshop includes tons of examples, all culled from real-world projects.
Like hamburger & fries and turkey & dressing, JRuby allows you to harness the awesome power of Ruby in your Java projects. This workshop describes the origins, capabilities, and limitations of JRuby, the 100% pure-Java implementation of the Ruby programming language. This workshop also demonstrates some areas where it makes sense to mixin Ruby and Java code: building swing applications, testing, and dynamic programming. This workshop includes tons of examples, including side-by-side comparisons of Java and equivalent JRuby code. It also covers some more advanced topics like building domain specific languages, meta-programming (including real uses!), and more.
