The Art of AgileSM
“More than anything else, Jim taught us how to think about large-
—Jim Gochee, Chief Product Officer, New Relic
05 Apr, 2006
I'm the kind of person that likes logical frameworks and structures. When I think about design, I can't help but wonder: "What's the intellectual basis for design? What does it mean to have a good design?" My answer, and the conlusions it leads to, are the most important things I keep in mind when considering a design.
10 Oct, 2005
Technology is constantly changing. How are your programmers keeping up? In this article, I describe a simple approach to learning that can be done every week and doesn't require classroom time. (Article hosted on java.net.)
17 Aug, 2005
On Feb 3, 2005, Robert S. Mueller III, director of the Federal Bureau of Investigation, appeared before a Senate subcommittee to explain how the FBI had managed to waste US$104.5 million. Sadly, the loss was entirely avoidable: The FBI made many classic mistakes. In this article, I'll take a look at three of these mistakes and apply lessons learned from the agile software movement. (Article hosted on SD Times website.)
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.
09 Feb, 2005
For years, I was an active participant in Ward Cunningham's Wiki-Wiki Web. A lot of my best work is still on that site. I'll be moving it here over time, but for now, check out the original Wiki for more of my writing.
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.
01 Sep, 2004
Many people recommend writing software so that it automatically works around errors. This results in software failing in mysterious ways later on. "Fail Fast" means writing your software to fail immediately and visibly when an error occurs. It results in more robust software with fewer defects. (Article hosted on Martin Fowler's website.)
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.
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.
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.
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.
01 Jan, 2004
Continuous design is the process of using refactoring to continuously improve a program's design. In this article for Martin Fowler's IEEE Software "Design" column, I discuss my experiences with continuous design, particularly with seemingly difficult scenarios such as internationalization and transactions. (Article hosted on Martin Fowler's website.)
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.
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.
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.