I have been building software all my adult life and in the process have developed an awareness of the almost infinite variations on the software development process. On this page, I attempt to provide simple definitions for the elements common to most software life cycles.
Steven Covey in his “Seven Habits of Highly Effective People” lists as habit 2, “Begin with the end in mind”. Unfortunately in my entire career, I have never met a customer who had a clear picture of what he needed from a software solution when the project started. Inevitably, I had to work through a process of asking questions about how they wanted the software to work. Often, I had to ask the same question several times, but coming from a different angle. For example, when I was building an inventory application during my very first job, I interviewed the manager in charge and the conversation went something like this:
- Jones: “I understand that when X happens, you want me to do Y. Is that correct?“
- Manager: “Yes“.
- Jones: “Is that correct 100% of the time?“
- Manager: “No, it’s true about 90% of the time, but you don’t need to worry about the other 10%.“
He really did not understand that the software must handle 100% of the cases. In his case, 10% of the time we could wind up doing something random.
The purpose of this process is clarity. Before we write code, before we design a database, before we think about user interfaces, we must understand what the solution is required to do.
Unfortunately, creating clear requirements gets ignored or cut short way too often. The end result is usually that the solution costs lots more to build and can even wind up very unstable. Just look at the Obama Care roll out for an excellent example of a software solution that had mushy requirements. One of the major problems with that roll out was that the customers were changing the rules way too late in the game. A requirements change that happens early on can often be fixed pretty easily; however requirements that change late in the life cycle can cost orders of magnitude more to implement.
If corporations are people, then I guess software is alive; and every living thing has a cycle that begins at birth and ends (usually) at death. Software is no different. It starts as an idea… a gleam in daddy’s eye, if you will. The idea gets fleshed out during requirements definition (see above), and then begins the process of creating a solution that meets the requirements. The process of building software is called a “Software Development Life Cycle” or SDLC.
An SDLC can be simple or complex, and the specifics of the process depend on many variables: what is the infrastructure that the solution will be built on? What volumes can be expected? Where are the customers? How will customers interact with the system? Fortunately, virtually all SDLCs can be categorized as a variation on the “Waterfall Method” or an “Iterative” model.
Perhaps the most famous example of the waterfall method is DOD-STD-2167A which was published in 1988 and describes the process the Department of Defense wanted contractors to use. This diagram exemplifies this process.
One of the major accounting/consulting firms developed their own multi-volume SDLC a number of years ago. One of their skeptical senior managers decided to put the process to the test. He walked around the office and wherever he spotted their SDLC manuals, he inserted his business card at a random place in the document and wrote on the back, “This card redeemable for dinner for two at [some restaurant]”. A year later, nobody had claimed their reward.
Conclusion: Complex SDLCs cause more problems than they solve.
On the other end of the spectrum are iterative processes like “Design/Build” where the wings of the airplane are attached mid-flight. I say this lightly, but it is the process I have been using for most of my career. The process starts with getting a reasonable understanding of the business problem, designing the database and using it to ask questions about the details of the business process, then building a user interface on top of the data. Typically, this process iterates many times, but it shows results very early on and often getting quick results is the key to keeping the project alive.
Several years ago, I was asked by a local business to build a solution for their on-the-road sales persons. They wanted it to run on the laptops of the sale people so that they could produce a quote in the field and get it signed on the spot. Then they asked the classic question, “How much will it cost?” Not really knowing exactly what “it” was, all I could do was give them a very rough ball-park estimate. Beware: that is the ONLY number the customer will ever remember!
A year later and dozens of iterations through product, refining and changing the requirements each trip through the process, they had a solution that worked wonderfully, but it had come in at over three times the original cost estimate. Once it was operational and working for several months, I took the business owner and the other key players in the project out to lunch and asked the owner, “If you knew when the project started what it would ultimately cost, would you have said ‘Yes’?”
“No way”, he replied. “But looking at the results, we would have been fools not to go forward.”
So welcome to the real world where the real cost is usually just as fuzzy as the real requirements and the wing configuration can change mid-flight.