Inspirational Talks

• The Economics of Software Design. Every month, someone new asks me the question, “How do I convince my manager to let me refactor?” While it’s true that a manager shouldn’t constrain the programmer’s plans to deliver high-quality code, the fact remains that some organizations allow their managers to assert this level of micro-control. In this talk I outline a set of models for justifying evolutionary design with basic economic concepts that relate directly to delivering, planning, and funding software projects. This talk will provide you with a solid argument to meet any skeptic’s rational objections to writing tests first and letting both low-level design and architecture emerge.
• The Selfish Team Player. Take care of yourself so that you can give more to the team. A starter’s guide for how lightweight software development techniques can help us reduce stress, finish tasks sooner, and interact better with the people around us—even when emotions run high. You can start doing some things today that yield results without anyone else’s coordination, agreement, nor permission.
• Programming Is the Easy Part. First, how to “master” programming in 3-7 years with a small number of lightweight techniques. Next, how to manage both time and energy to finish tasks sooner with less stress. Finally, how to interact more harmoniously with the people around you. Once you start exploring these topics more deeply, you’ll see that for a professional programmer, the programming really is the easy part.
• Manufacturing Slack. One of the most common things I hear in my training and consulting work is “That sounds great, but we don’t have time.” This is how people routinely react to learning something new: they’re learning something because they’re in trouble, but they don’t see how they’ll have the opportunity to apply what they’re learning to get out of trouble. This seems like an inescapable trap that dooms any significant learning effort to failure. Organizations usually already have all the resources they need to make use of what they’re learning, but often the people involved either can’t see them or don’t feel safe using them. In this talk I outline a method for finding the slack resources that you need to finally make those improvements that you’ve wanted to make for a long time. I also include a frank discussion of the psychological barriers you’re likely to encounter along the way and some ideas for how to manage them. You can do it, but you’ll probably have to deal with some discomfort along the way. I’d like to help.
• Breaking Through Your Refactoring Rut. Many programmers and teams struggle to realize the benefits of evolutionary design, because they never quite become comfortable with refactoring. It always feels too slow, too difficult, and instead it feels quicker and easier to jump in and rewrite parts of the system, even though that too often leads to getting stuck, falling victim to the sunk cost fallacy, and “rolling forward” when it would be much more prudent to throw it away and try again. In this talk, I describe why programmers often reach a plateau in their refactoring skill and suggest some practical ways to break through, so that evolutionary design starts to feel easier than doing things the old way.

Questions and Answers

These talks work best at interactive events, like user groups and meetups. We begin with a topic, I make a relatively brief opening statement, then I take questions from the audience. This leads to a combination of talk and group discussion. Any topic in software development is fair game and we often wander outside the original theme, if that’s where the audience wants to go.

I also use this format to demonstrate incremental delivery: if we have too many questions for me to answer thoroughly in the remaining time, then I provide a shorter answer for every question, then invite follow-up questions until we run out of time. This way, at least every question gets an answer.

The Classics

Even as I explore new ideas, these talks remain popular, and I’m happy to continue running sessions on these topics.

• An Introduction to Agile with the Theory of Constraints. When you first read about agile software development, you probably notice a collection of practices: pair programming, releasing frequently, planning weekly, meeting daily. What do these practices have to do with delivering better software sooner? In this talk, I introduce some essential concepts from the Theory of Constraints, then show why common agile practices help us deliver more value to our customers sooner.
• Yes, Your Agile Transition Can Work. Many companies try to “go agile” without a definite plan, and it results in utter chaos. You don’t have to follow that path, even if you suspect that senior management has made this very common strategic mistake. You can recover from it, overcome it, and succeed, but only if you understand the good business reasons to “go agile”. In this talk, I share some key points about change initiatives that your organization might not have considered, insist that it’s not too late to change course, and give you some tools to adopt agile practices, principles and values successfully.
• Beware the Integrated Tests Scam. In this talk I discuss the viral nature of integrated tests, how they consume an organization’s precious energy, dominate the cost of a project, and leave people feeling like automated testing hurt them rather than helped them. I describe a simple method that programmers can use to free the project from the tyranny of the integrated test, relegated it to what it does best: helping us diagnose and fix system-level problems.
• Surviving Your (Inevitable) Agile Transition. Many companies try to “go agile” without a definite plan, and it results in utter chaos. You don’t have to follow that path, even if you suspect that senior management has made this very common strategic mistake. You can recover from it, overcome it, and succeed, but only if you understand the good business reasons to “go agile”. In this talk, I share some key points about change initiatives that your organization might not have considered, insist that it’s not too late to change course, and give you some tools to adopt agile practices, principles and values successfully.

Booking

I am happy to receive your invitation to speak at your event. Please consider the following:

• I am often available to volunteer at non-profit events, but otherwise I charge a fee for speaking engagements, including private/internal conferences.
• If you’re inviting me to speak at your conference, then I would like to discuss organizing a public training course to run alongside the conference. The profit from the training course could eliminate the need for the conference to pay a speaking fee.