My Software Craftsmanship book is now available in bookstores everywhere, as is Questioning Extreme Programming.

Feb 2003 What to do when the Estimate is Wrong a lighthearted look at how projects get estimated, and how project disasters happen.

InformIT has post a series of my articles throughout the start of 2002.

• Avoiding Death March Projects explains why death march projects are not inevitable.
• Exposing the Fallacy of Good Enough Software asks every manager, team leader, and developer to fight back against the idea that bugs are inevitable.
• Dismantling The Waterfall Of all the ways of approaching the software development lifecycle, the waterfall is probably the worst. So why does it continue to dominate our thinking? Simple: We have failed to let everyone know how software development really works.
• How not to get burned by your next Java project. This article follows up on "How to Crash and Burn Your Java Project" with survival strategies for developers so that the impact of poor decision-making is minimized.
• Learning How To Be A Developer Does the popular "sheep dip" model of short training courses actually help people become better developers? Is teaching as a performance art really the way to go? The time has come to shift our attention away from teaching and think instead about what it takes for people to really learn how to be great developers.
• Implications of Software Craftsmanship By replacing the traditional software engineering metaphor with software craftsmanship, we open a whole new realm of possibilities for the software development community.
• Pretending to be Agile Agile is in. Many processes and projects are jumping on the bandwagon and claiming to be Agile, so what are the telltale signs that what you have is a traditional process just pretending to be Agile?
• What are XP projects scared of? A chapter extract from Questioning XP
• Becoming a Software Developer series on InformIT. In the age of objects and the Internet,these articles show how Ruby fits a whole new generation of developers.
  • Part 1 Ruby for the Nuby When first learning how to write software, immediacy wins every time. Beginners are helped by the immediate feedback that comes from interpreted languages. Many developers first learned to program using interpreted BASIC on a home computer. In the age of objects and the Internet, Ruby can fulfill the same role for a whole new generation of developers.
  • Part 2: Test Driven Development with Ruby Developers can become more productive and spend a lot less time debugging code by creating Extreme Programming style unit tests before the rest of the code is written. Every "Ruby nuby" should learn about test-driven development and create unit tests.
  • Part3: Version Control for Fun and Profit Although version control is an old technology, few developers take the time to think about how it can help them become more effective. This article looks at how frequent versioning can take some of the stress out of software development.
  • Part 4: Understanding Use Cases and Requirements Where do requirements come from? How can use cases help to record requirements? What does a good use case look like? What do I do with a use case once I have it?
  • Part5: Creating Acceptance Tests from Use Cases Use cases are a fantastic aid to quality assurance activities because they provide the information we need to design acceptance test cases.
  • Part 6: Design and Programming or Why Programming is Hard The step between having a design idea and the "simple matter" of programming that idea is a massive one. Understanding why programming is not easy is a first step toward mastering the craft of programming.
  • Part 7: Ruby for the Internet Nuby It's easy to write simple scripts for sending emails but hard to make sure that your application deals with all the weird and wonderful things that can go wrong.
• Quality By Design Part 1: Avoiding Rotten Code We all have to face the fact that some software stinks; it doesn't work right or it just plain feels wrong. Fixing these problems is simple, but may not be easy. We have to understand the nature of software development and make sure that we allow ourselves enough time to do a good job.
• Quality by Design part 2: Healing Legacy Code Many organizations complain that their legacy systems are unmaintainable, but guess what? The organization let the code get that way by not paying attention to the design of the teams that created and maintained the code. Refactoring the code may provide a stopgap measure, but refactoring the organization is a better solution.
• In Praise of C and C++ See why many developers prefer C and C++ over other rapid development tools. C and C++ enable developers to create long-lived predictable applications and to interface to legacy code on practically any platform.

Incremental Development, a followup to the earlier Incremental Requirements article, looks at what it means to do Incremental Development from the point of view of the development team and the users of applications.

How to Crash and Burn your Java project Since many Java projects seem destined to fail I though that it would be useful to provide some advice on how to speed up the process. This article is a parody. Any resemblance to your project is purely coincidental and should not be taken as any indication that your project will actually succeed in it's goals.Also available on the InformIT Website: How to Crash and Burn your Java project (login required, registration is free)

Applying the Lessons of eXtreme Programming (36K pdf) Although eXtreme Programming has been explained by Kent Beck, there are many benefits to adopting eXtreme Programming (XP) practices in other development processes. The benefits of adopting the complete XP approach are outside of the scope of this paper, what is discussed here are the lessons that XP offers to other development processes. This paper initially discusses the benefits available from adopting XP style unit testing on a project, and then moves on to identify useful lessons that can be learned from other XP practices. The paper concludes by asking questions about the nature of process improvement in software development and how we can make our software serve society. Please note that this paper is © 2000 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

Is XP for Everyone? Although eXtreme Programming is very visible right now and is starting to dominate the conversation about Lightweight or Minimal Methodologies, there are many alternatives available. Read on to ponder the question "Is XP right for your team or not?"

Test Cases from Use Cases Creating Test Cases from Use Cases turns out to be very easy when using Alistair Cockburn's format for Use Cases, testers will thank you for using use cases.

Using Use Cases for Requirements Capture Use Cases have proved to be an effective mechanism for the capture of requirements. This document uses Alistair Cockburn's format for Use Cases and adds in ideas about how to create and review Use Cases.

Incremental Requirements (at the Extreme Programming website). This paper talks about the distinction between of Capturing Requirements for Prioritization and Capturing Requirements for Implementation.

Creativity in Software Development Creating Software is one of the most creative activities that humans undertake. The main limitation in software is the Human Imagination, and the limits on that are all self imposed. Through the Software Engineering model we see a linear, sequential model of Software Development, something that drastically reduces our ability to create really great software.

Uncertainty in Software Development Uncertainty is one of the few certainties about software development. As humans we are not very good at creating precise estimates, but we all crave precision when we recieve estimates from others. This paper explores these ideas. The book Inevitable Illusions covers similar ground in a lot more detail.

The Myth of Change Control The Software Engineering model of Software development has a major flaw. There is an association with a linear, sequential process, we even have a neat name for this linear, sequential process, the "Waterfall" life cycle, where everything flows neatly from one stage or phase to another. Although this "waterfall" process of software development has supposedly been proven to be invalid, most software developers still talk as if it is alive and well.

OOPSLA 99 Design for maintenance workshop details are available. As are the TOOLS USA 2000 Workshop on Education and Training (WET) details.