Making Mistakes… Faster
Years ago, when computing power was incredibly expensive, software development processes were borrowed from
other engineering efforts like construction. If you were a good engineer, you avoided mistakes by spending vast amounts of time designing your bridge up front: determining every length, triple-measuring every piece of steel, and verifying everything in advance, to minimize the possibility of an error when you finally assembled it. Along the way, you’d create lots of design documents and blueprints, which you’d ultimately send off to be forged into iron parts. And you’d wait. A year or more later, when all the pieces were finally ready, you could begin to build your bridge.
This approach that emphasizes getting all of the requirements and design done first, and then builds to a fixed blueprint, is more commonly called “Waterfall” engineering. Each step – specifications, design, assembly – must be completed and signed off before the next step begins – like a series of waterfalls in a cascade. Of course, if you did make a mistake, this approach made changes extremely difficult, time-consuming, and expensive. Work on the entire bridge might have to be stopped while a new piece was made. In practice, however, that was usually fine because changes were few or minor: there just aren’t many new and different ways to use a bridge once it’s built, and no value in using any of it before it’s complete. It might even be deadly to try.
For years, the same “Waterfall” philosophy was also used to develop software, but as everyone knows, software doesn’t work like that: software is different. Software can often be usable long before all features are fully complete. In addition, just using it immediately gives us ideas on other ways to use it, or other audiences who could benefit from it. So Waterfall engineering struggled in software because it assumed everything can be known and defined up-front. It failed to anticipate the many changes that naturally occur once a product is used – new ways that were often unimagined. These changes make it necessary to rework the design, which in turn causes reworking of the code. Schedules, which historically assumed minimal changes, began to slip. And software development projects began to fail – to the tune of 50% of all large software projects failing to deliver on time and on budget. There had to be a better way.
Enter the “Agile” development methodology. (Read more about its principles here). Today’s rapid development tools and computing power allow us retool more quickly, making it possible to anticipate and ultimately respond to changes in requirements better and faster than before. The Agile approach strives to deliver smaller, but usable units of functionality to users as soon as they’re available, in order to get the feedback earlier. Agile emphasizes real feedback from real people over formal design documents and specifications. It believes that getting a little working functionality right and fast is better than a lot of functionality later. And Agile fully anticipates that invaluable moment of “yes, that’s what I asked for, but now that I see it, it’s not what I want.” In short, Agile encourages us, as legendary Intel CEO Andy Grove once put it, to “Make mistakes… faster.” Of course, this approach isn’t perfect, and could lead to a feature that’s not fully complete, done incorrectly, or needs to be reworked. But that’s largely the point. If we’re heading down the wrong path, we want to know that as soon as possible, and tune our processes to be able to react quickly. If waterfall engineering struggles because of our natural inability to see how we’ll use software until we see it, Agile delivers what it can, expects change, and gets to the “change moment” sooner…. to “Make mistakes… faster”.
At SofterWare, we have embraced the Agile methodology to get the best working, most delightfully easy to use software we can in front of clients – as quickly and efficiently as possible. This year, we shipped several key DonorPerfect features using this method, including our SideBar Reporting tool, our new Screen Designer, and most recently, our filters management upgrade. Each of these features was rolled out early with limited functionality at first that improved with each release. Those improvements came directly from client feedback, and we’re incredibly grateful for it. We want to know when we’re doing it right and when you, our clients, think we’re heading in the wrong direction. As a client, your opinion matters! Use the forums and our “Suggest and Vote” (login required) feature to let us know what you think!
other engineering efforts like construction. If you were a good engineer, you avoided mistakes by spending vast amounts of time designing your bridge up front: determining every length, triple-measuring every piece of steel, and verifying everything in advance, to minimize the possibility of an error when you finally assembled it. Along the way, you’d create lots of design documents and blueprints, which you’d ultimately send off to be forged into iron parts. And you’d wait. A year or more later, when all the pieces were finally ready, you could begin to build your bridge.
This approach that emphasizes getting all of the requirements and design done first, and then builds to a fixed blueprint, is more commonly called “Waterfall” engineering. Each step – specifications, design, assembly – must be completed and signed off before the next step begins – like a series of waterfalls in a cascade. Of course, if you did make a mistake, this approach made changes extremely difficult, time-consuming, and expensive. Work on the entire bridge might have to be stopped while a new piece was made. In practice, however, that was usually fine because changes were few or minor: there just aren’t many new and different ways to use a bridge once it’s built, and no value in using any of it before it’s complete. It might even be deadly to try.
For years, the same “Waterfall” philosophy was also used to develop software, but as everyone knows, software doesn’t work like that: software is different. Software can often be usable long before all features are fully complete. In addition, just using it immediately gives us ideas on other ways to use it, or other audiences who could benefit from it. So Waterfall engineering struggled in software because it assumed everything can be known and defined up-front. It failed to anticipate the many changes that naturally occur once a product is used – new ways that were often unimagined. These changes make it necessary to rework the design, which in turn causes reworking of the code. Schedules, which historically assumed minimal changes, began to slip. And software development projects began to fail – to the tune of 50% of all large software projects failing to deliver on time and on budget. There had to be a better way.
Enter the “Agile” development methodology. (Read more about its principles here). Today’s rapid development tools and computing power allow us retool more quickly, making it possible to anticipate and ultimately respond to changes in requirements better and faster than before. The Agile approach strives to deliver smaller, but usable units of functionality to users as soon as they’re available, in order to get the feedback earlier. Agile emphasizes real feedback from real people over formal design documents and specifications. It believes that getting a little working functionality right and fast is better than a lot of functionality later. And Agile fully anticipates that invaluable moment of “yes, that’s what I asked for, but now that I see it, it’s not what I want.” In short, Agile encourages us, as legendary Intel CEO Andy Grove once put it, to “Make mistakes… faster.” Of course, this approach isn’t perfect, and could lead to a feature that’s not fully complete, done incorrectly, or needs to be reworked. But that’s largely the point. If we’re heading down the wrong path, we want to know that as soon as possible, and tune our processes to be able to react quickly. If waterfall engineering struggles because of our natural inability to see how we’ll use software until we see it, Agile delivers what it can, expects change, and gets to the “change moment” sooner…. to “Make mistakes… faster”.
At SofterWare, we have embraced the Agile methodology to get the best working, most delightfully easy to use software we can in front of clients – as quickly and efficiently as possible. This year, we shipped several key DonorPerfect features using this method, including our SideBar Reporting tool, our new Screen Designer, and most recently, our filters management upgrade. Each of these features was rolled out early with limited functionality at first that improved with each release. Those improvements came directly from client feedback, and we’re incredibly grateful for it. We want to know when we’re doing it right and when you, our clients, think we’re heading in the wrong direction. As a client, your opinion matters! Use the forums and our “Suggest and Vote” (login required) feature to let us know what you think!
No comments yet