Product vs. Project
There are many ways for a business to release software. Two common approaches are projects and products. They sound similar but are vastly different.
Project releases are often big-bang, all-or-nothing style of releases. Projects can often take months or even years to release. The software tasks are typically tracked with gantt charts and is often managed in a waterfall-style. The schedule is typically considered the most important component in this model. In addition, projects typically require vast amounts of documents prior to the first line of code being written. These documents include requirements, high-level design, detailed design, use cases, test scripts, and countless others. Project releases are often used by “enterprises” to release software.
Most of the projects I have worked on have failed. Those projects that were successful typically failed within a year. When a project completes, the organization will move their human resources to a new project leaving noone to maintain the software. Software is rarely done. Projects seem to encourage software developers to take shortcuts to make the due date.
Product releases on the other hand, typically do not have a finite end date. Software is released in feature and bug fix increments. A software roadmap help guide the development effort. These roadmaps provide a general idea of when features will be implemented. Since there is no end date, the software developers can evolve the codebase. This helps create a clean, maintainable source tree. Developers typically take more pride in their work. They know that the shortcuts they take today will affect them in the near future. The most important component is this model is working software.
In my experience, software managed in the project model feel heavy and slow. Whereas, the product model seems a lot lighter and quicker. I prefer to work on products and not projects. What type of release model do you prefer?
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)