I just stumbled upon a blog posting by Chad Myers titled “Good Design is not Subjective.” It’s hard for me to believe, but apparently this is a controversial subject in the software community today.

Jerry’s challenge with raising the target donations is similar to the challenges we face in estimating and delivering software projects on time. He has no way to precisely estimate how much money he can raise in the 24-hour event, yet he has a target, and he always exceeds it. Similarly on software projects, teams are asked to deliver a fixed set of requirements on a fixed date, but unlike Jerry, we are rarely successful in delivering everything on time.

Recently, when playing FreeCell to take my mind off an essay I was writing, a thought occurred to me: FreeCell illustrates the value of upfront analysis and design. On a number of essays on yuwantitwhen.com, I’ve advocated that doing proper upfront analysis and design on our software projects is the best way to secure success for your projects and to shorten schedules. Similarly, in FreeCell, I’ve won more games on the first try when I devoted more time to upfront analysis and developing a strategy.

by Mary Poppendieck
Mary Poppendieck speaks at a Google TechTalk on the role of leadership in software development. She presents an interesting history on the philosophy of management and how it has morphed over the years to …

As a subscriber of Businessweek, I usually start from the back. That’s where Jack and Suzy Welch answer questions from the readers. In the June 30th publication, there is a quote from the Welch’s that hits upon a recurring theme of mine, and I’d like to share it. They talk about the challenge of balancing future requirements with current requirements.

The second quarter was another successful three months for yuwantithwhen.com. A number of essays were very popular with the site’s visitors. The most popular essay for the quarter was “Why It Takes So Long.” Thanks to Steve Johnson over at Pragmatic Marketing for directing his readers to the posting. There are often very good reasons it takes longer than expected to deliver a software product, but there are things that we often do to make projects take longer than they should. I’m thinking of writing the sequel to the essay: “Why it Takes Longer Than it Should.” I’m not sure when I’ll pen that one, but it’s in the queue.

The web changes everything. Now that so much software is offered for free, the cost barrier for switching vendors is gone. Consequently, high quality is even more important when the barrier to switching vendors is nearly zero. Many times, quality is more important to your customers than new features.

It’s suggested that the web has changed everything. Whatever requirements there were for delivering desktop applications, the requirements for delivering web applications has changed. For the web, the thinking goes; delivery of new features to customers is paramount to remain competitive. Maybe it’s true, but what’s the evidence? My own experience with popular web sites does not support this conclusion.

David Starr argues that Agile doesn’t work because business operations aren’t Agile, and his remedy is to have Agile business practices that embrace change: “Embrace continuous integration of the enterprise.” Customers don’t want continuous change; they want a great product the first time they purchase it, so they can spend more time serving their customers and invest more money on other important needs. While your product delivery is most important to you and your company, it’s likely not the most important need for your customer. Agile simply solves the wrong problem.

Delivering software requires courage. In “Extreme Programming Explained”, Kent Beck explains, “Sometimes courage manifests as patience.” The practice of software development requires the leaders and the team to have faith in their development practices and the courage to stay with them when fear gives you doubts. Who said software development is easy?