Software is hard. It’s a pain in the process.

Post by Ben Edwards

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?

About Ben Edwards

Designer of information and interactions; contributes as much with enthusiasm and drive as anything else; generalist; can migrate easily between discussions of databases, use cases, and Photoshop techniques; avid blogger (from the days when it didn't have a name); critic of bad design; organized and presented at the minnebar (un)conference in Minneapolis; married, no children, dog; loves travel. alttext.com, minnestar.org, @alttext
This entry was posted in Agile Processes and tagged . Bookmark the permalink.

Related Posts:

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>