Crunch Mode

24 Feb, 2005

Software organizations are famous for requiring their programmers to work long hours in order to meet deadlines. "Crunching" takes a heavy toll on workers, damaging personal relationships and health. It's also hard on code: tired programmers under pressure are much more likely to incur design debt, which erodes your software investment. Ironically, crunching doesn't help teams meet their deadlines. The only way out is to not get in: when you find that estimates were wrong, take the bull by the horns and admit it your customer.


Beyond Defects

01 Sep, 2004

Quality comes in several forms. Although many people think of quality as "number of defects," defects are really only a symptom. In this newsletter, I talk about how to find and solve the quality problems that underlie defects.


Task Switching

01 Jun, 2004

Organizations frequently do more projects than they can handle by assigning developers to multiple projects simultaneously. This looks fine on paper, but it ignores a central cost of software development: the cost of task switching. Assigning developers to one project at a time is an easy way to increase productivity. Although this will decrease the number of projects people are working on, they'll get done faster and your developers will accomplish more overall.


Research Time

01 Apr, 2004

It's easy to try: give your developers half a day every week to indulge in self-directed technical exploration. Research time works because developers are typically motivated by a desire to do good work, particularly when they're self-directed. Most developers' natural desire is to make their lives easier and to impress their colleagues. As a result, the work done in research time often has a surprisingly high return for the product being developed.



01 Mar, 2004

Trust--actually, lack of trust--is the source of many common software development practices. These practices mitigate some risk of working with distrusted parties, but they're inefficient, even harmful. We produce better, more valuable software when we replace distrust-based practices with a strong, trust-based relationship... although that's easier said than done.


Design Debt

01 Feb, 2004

Companies often retire useful software because it has become too expensive to maintain. When this happens, it's because the design quality is decreasing. Since retiring or rewriting software means writing off a huge investment, you wouldn't expect any team to let design quality deteriorate to that point. Yet it happens all the time. You can break the cycle by making debt reduction an ongoing process.


Phased Releases

01 Jan, 2004

One easy way to increase the value of your project is to deliver in phases rather than in a single monolithic release. In an example, ROI jumped from 47% to 188% (!) just by delivering multiple releases. It improved the internal rate of return for the project from a borderline 13% to a very healthy 36%. Costs went up slightly, but cash investment went down and the project became self-funding sooner.


Choosing the Right Projects

01 Oct, 2003

I had the opportunity to hear Tim Lister speak at a recent conference. "The biggest risk an organization faces," he said, "is failure to choose the right projects." One way to find out if your projects are valuable is to look at their deadlines and schedule. An arbitrary deadline, aggressive schedule, and no slack might mean that the project isn't very valuable. This sort of development has an ugly cost curve: initially low, then shooting up out of control at the last minute as the delivery date is postponed.


Passion and Discipline

02 Aug, 2003

I think the most important difference between a successful team and a failing team is the passion and discipline of the team. Discipline because software development is a difficult, detail-oriented, time-consuming profession. Passion because the invisibility of software quality means the programmer has to truly love producing high-quality work.


Defining Success

22 Apr, 2003

It's not enough to deliver what the client specified, when the schedule says, and according to budget. A truly successful project delivers what the client needs, starts achieving ROI early, and ends when the cost of new features exceeds their value.