We are what we repeatedly do. Excellence, therefore, is not an act, but a habit.
As software developers, we want our products to be excellent. Our desire is to delight our users with bug-free experiences and to ensure the highest quality in the programs we create. Among our peers, we strive to demonstrate our technical prowess with the elegant and stable code we write. Each of us works hard at achieving these goals every day. Our repetitive efforts to develop high-quality software, coupled with our desires to continually improve our methods and practices, solidify our habits as developers. As Aristotle suggests, excellence is achieved through repeated great execution.
Building high-quality software is a difficult job, though. Even the most rudimentary programs will have bugs. Everyone, including the best engineers, put them there. Humans, by nature, are imperfect and occasionally slip up. As we translate human instructions to a software application that we want to do our bidding, mistakes will be made, exceptions will be thrown, and, yes, quality problems will arise.
But it’s unfair to pin responsibility for software quality solely on developers. Software engineering is a process involving many participants from different disciplines. At Microsoft, for instance, engineering teams are typically divided into three disciplines: Program Management, Development, and Test. Program Managers ensure that product specifications are precise and well thought out, and they set definitive goals for the quality of the end product. Developers create the most efficient and flexible designs, ensure accuracy of the algorithms, and leverage well-known best practices for code implementation. Testers consider every possible permutation of both code and application behavior and fully examine and exercise each code path of the software. Quality is part of the end-to-end engineering life cycle and therefore is every participant’s responsibility. Software development organizations understand this principle and go to great lengths to implement processes and programs to ensure that quality is a core focus for each team member.
Software development processes and methodologies have existed in the industry since the late 1960s. As computing power increased, software programs grew increasingly more complex. This increased complexity in software development, and the relative immaturity of the industry, led to several problems with software projects, including cost overruns, poor-quality software due to lack of formal quality processes, and low maintainability of code. As a result, formal software development processes were born. Their primary goal was to put formal structure around a series of tasks that ultimately led to an improved outcome of the development effort. Simply stated, the goal of having formal engineering processes was to achieve a higher-quality product and a more predictable time to market or deployment. Using a process to ensure the quality of a product is fundamental to delivering nearly any product or service, regardless of industry. Chances are, as software developers, you have experienced one or more different project management methodologies during your career, such as waterfall, agile, or even the Microsoft Solutions Framework (MSF).
You have probably heard the term "waterfall" applied to the more traditional software development life cycle (SDLC). This term refers to the way each phase of the SDLC cascades steadily downward, as shown in 1-1, through the following sequential phases:
Requirements. A detailed, written description of the software to be built.
Design. The process of planning the implementation details of a software project.
Implementation. The process of coding, testing, and debugging the individual parts of the software being developed.
Integration and verification. The phase when the various portions of the software are being brought together for integration and broader testing.
Installation and maintenance. The end of the SDLC, when the new software is deployed and moves into a cycle of post-release fixes and adjustments.
The model’s rigidity requires sequential forward progress through these phases until the software is completed and requires that each phase be completed before the next can begin. Requirements specification must be fully completed before proceeding to design. Once design is completed and a plan is in place for engineers to implement the requirements, coding begins. Integration follows coding, and the various parts of the program are brought together and tested as a complete system. Once integration is complete and the software is deployed, the maintenance phase starts. In each of these phases, a great deal of emphasis is placed on written documentation as well, which tends to make waterfall projects heavyweight.
The waterfall model approaches quality by suggesting that the more time spent analyzing and designing the software, the more likely flaws will be uncovered early in the process and subsequently avoided in the downstream development of the code. Critics argue that this methodology does not work well in practice because critical details of the program or application cannot truly be known until the development team is progressing through implementation. Additionally, since the model is stringent about finalizing specifications before coding begins, there is very limited opportunity for including any early customer or beta tester feedback into the release cycle, which constrains the team in addressing customer needs in a timely manner. Finally, complete end-to-end testing does not occur until late in the cycle, which adds risk to the quality of the application, when integration of critical elements begins.
Note
The "waterfall" methodology is often credited to Dr. Winston W. Royce, based on a paper he authored in 1970 titled "Managing the Development of Large Software Systems." The irony of this accreditation is that Dr. Royce was essentially arguing that the methodology was risky and invited failure. He mentioned how testing at the end of the life cycle, where all critical components of the system are coming together for the first time, was not realistic. He went on to suggest that flaws discovered late in the cycle would lead to inevitable cost overruns due to the high likelihood of subsequent design changes. Although he believed in the conceptual idea of the multiphased life cycle, he desired an evolution to a more iterative approach that would likely achieve a better result than a sequential model.
Proponents and opponents aside, the waterfall method of software project management has provided a framework for many of the derivative models that exist today. Just as the late 1980s and early 1990s saw the evolution of Rapid Application Development methods, in recent years, many organizations have moved toward agile development methodologies, both of which are derivatives of the waterfall methodology. These newer models are much more iterative in their approach to the software development process, and they promote shorter, quicker, more focused release cycles.