Imagine you’re ready to build your dream house! You have a high level idea of what you want and have lots of specific requirements for the style, size, space, and interior finish. To convey your vision, you begin a series of discussions with the builder you have selected; let’s call him Charlie. Charlie seems to know what he’s doing and you have faith in him because he builds houses all the time; he’ll know what to do if you have left out any details.
Charlie comes up with a ballpark estimate on price. Everything’s in order and the construction process begins. Three months later you get a call from Charlie saying he has completed the work and he’s ready for you to walk through the house. As you drive up you realize the house looks nothing like you had imagined it would. Walking through, you find that Charlie made a lot of interpretations of your requirements because he either didn’t understand what you wanted or something didn’t fit well within the schedule or budget. Later, you find that the budget was compromised anyway and you owe him 40% more than you had originally planned to spend. If that’s not bad enough, you didn’t get what you envisioned and will need to put a lot more money into the house to make it even bearable to live in.
Needless to say, this doesn’t sound like an experience any of us would like to have. In fact, I don’t know of anyone who would use this process to build a house. Scary thing is, many business software development projects go just like this! We have witnessed or heard countless tales of experiences very similar to this. Remarkably, the process is often repeated over and over again with hopes of a different outcome. So what’s the problem? I’ll start searching for the answer by first looking at a better experience.
A Better Way to Build a House
Let’s try the house example again but this time we’ll start by working with a designer and an architect. They understand your “business” language and have the skill to convert your vision and needs quickly into models that accurately convey detailed requirements for the house. In addition, they can provide visual models that allow you to experience what you are creating before actually building it. This includes detailed blueprints, three color images, and 3-dimensional computer models that allow you to ‘virtually’ walk through the house prior to construction.
Armed with a well-conceived design with multiple representations of your requirements, you can now get accurate estimates from several builders and choose the one with the best experience/price. Once you’re satisfied that you’ve found the builder with the right experience, we are ready to begin the construction phase of the project. First, you agree on a process for managing and approving any changes that occur throughout the construction process. You also agree with the builder on both a formal and informal inspection process whereby the house is built in stages. You get to inspect (or experience) the house through each stage of the construction process. For the more technical areas, you scheduled a professional inspector to come in at just the right times based on the schedule. You stay involved throughout the construction process. If you see something out of place, you will bring it to the attention of the builder immediately. If the framers don’t build a doorway in exactly the place you had planned then you point it out. If the low voltage (speaker) wire didn’t get put in on schedule, we’ll be sure to catch it before the sheet rock crew arrives, and so on and so forth. By the time the end of the project comes around, there are no surprises. The detailed specifications gave us enough information to accurately estimate the cost and most importantly, convey the requirement as we intended to the builder and his entire crew of foundation, framers, carpenters, electricians, and finishers. The result, pure happiness!
Building a House vs. Building Software
So how well does home building map to software development? I would say pretty well. Like home building, software development projects are driven by solid project and requirements management. The second example reflects a simple but solid approach to managing both the project and the requirements. Requirements were clearly defined and communicated in multiple forms. Because a lot of attention was paid to what to build, before construction began, fewer mistakes would be made during construction. The project was broken into multiple phases making the project a series of mini-projects rather than one giant project. Lastly, with the construction process open to the stakeholders, careful inspection and verification was done very early through each phase of the project. Mistakes were caught when they were still relatively inexpensive to fix.
Now let’s look at how a modern software development approach relates to the experience of building a house. To begin, let’s explore where software development processes came from in the first place.
Origin of the Software Development Process
While the process of building houses has evolved for several thousand years, software development methodologies have come onto the scene in only the last 20 (some would say 30) years. Software development methodologies evolved from process improvement methodologies, primarily in the 70’s and 80’s. These process improvement methodologies were designed to improve business processes rather than build software. The basic process remained the same, but the activities performed throughout the process were changed for the purposes of building software. Many projects were successful; many more ended up in either failure or tied into a labyrinth of software where one piece of software was tightly glued to several others resulting in a large monolithic beast that is commonly referred to as ‘legacy’ software.
A Better Way to Build Software
Fast-forward to the 90’s and we began to realize the flaws associated with our approach to building business software. As the 90’s progressed, organizations such as Rational Software, who were at the front of this wave, began to propose better approaches to software development. The process included new buzzwords such as requirements management, software architecture, iterative development, use cases, and architectural prototypes. In addition, best practices evolved that dramatically improved our ability to manage software development projects. Here are a few:
- Develop Iteratively – to reduce risk and improve quality
- Manage Requirements – because software requirements usually evolve rather than materialize
- Use Component Architectures – because we expect software to be flexible over time
- Model Visually – so that business people, and software people can develop a common understanding of the system requirements and design
- Continuously Verify Quality – because mistakes caught late in the process can cost 200 times more
- Manage Change – because change is an unavoidable fact of software development projects.
Organizations that have adopted these practices are already aware of the significant long-term implications of writing better software. For these organizations, the cost of building software has come down primarily due to fewer failures; and, perhaps most importantly, they are meeting the needs of the business.
Interestingly, most organizations have made few if any changes to their internal software development practices. Many of these ‘broken’ processes are inflexible and require untrained stakeholders to write complete and detailed functional specification early in the project life-cycle and then throw it ‘over the wall’ to the software engineers for development much like our first house.
A Roadmap to Success
In short, the process of building software has come a long way in the last 10 years. Most organizations have not leveraged these techniques and continue to struggle with how to build software. Today, we have a much better understanding of how to manage the life-cycle of a software development project. We understand how to capture the requirements and design specification in a way that provides a common understanding of what to build. We have techniques for presenting requirements and designs in several different forms and can provide stakeholders and users with models that allow them to ‘experience’ the software before we actually write all the code.
I have found that making incremental changes to your software development practices is pretty straight forward and incredibly cost effective. You don’t have to (and shouldn’t) engage in a major initiative to ‘retool’ the company. Start with a pilot project. Work with someone who has done this successfully. Involve stakeholders from all across the business. Most importantly, communicate what you’re doing so everyone in your organization has an opportunity to be a part of the change.
About the Author
Scott McEwen is Director of Business Solutions at Metasys Technologies. He is a proponent of iterative development and has led numerous successful projects performing roles from engineer to business analyst, to project manager. In addition, Scott writes and conducts seminars on software development best practices and helps organizations improve their internal processes.
Scott can be reached at [email protected]