Software is hard. It’s a pain in the process.
Salon’s Scott Rosenberg is interviewed by Salon’s Andrew Leonard for his piece called Software is hard.
By this time, most people who have participated in software development projects any time within the last ten years, know that developing software can be very hard. What many people don’t realize, at least consciously, is that most of the difficulties of software development are procedural. The process is the pain.
Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software, is Scott Rosenberg’s attempt to tell the story of a specific software development project that went off-course. A project that, like almost any project, could have gone much more smoothly.
When asked about similarities between his project and the Windows Vista delays, Rosenberg has this to say about estimating software projects:
The one that comes first to mind is simply the incredible difficulty of estimating the time it takes to do this stuff, whether you are building a little content management system for a relatively modest-size Web company or whether you are building the operating system that will be used by three-fourths of the known universe. The difficulty in saying, A) How long will it take to do what you want to do? And B) When are you done doing what you want to do?
The problem with software development has been that the difficulties, overages, and letdowns have become the norm; they are an expected part of the process. We think this is sad, and also unnecessary.
Refactr, and many more companies, have come to the realization that trying to define and estimate everything up front simply doesn’t work. You cannot plan for the unknown and the many things that may occur throughout the course of the project. It is very difficult to ensure that everyone is envisioning the same end result. That’s why we advocate continuous requirements gathering and prioritization and why we deliver software that works at the end of each week. Change and the unexpected have been a part of every software project ever undertaken, why not plan for and accept it?
This entry was posted by Ben Edwards on Monday, February 5th, 2007 at 8:55 pm and is filed under Agile Processes. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.