Section 11.3. How to Develop Software

11.3. How to Develop Software

There is a science of Software Engineering. The development of software can be made an engineering discipline, with mathematical rules and metrics of success. Every aspect of a complete system can be worked out in detail beforehand so that you know, well before a line of code is written, what the outcome will be.

That's not what we're talking about here.

We are talking about software development not as it happens at NASA, medical device companies, and in factories where nuclear missiles are made. In those contexts, the potential costs of error are extremely high, ranging from the multibillion dollar loss (and public embarrassment) of crashing a spacecraft into Mars, on through having heart pacemakers fire off incorrectly, right to ending life as we know it on this planet. In such cases, no matter how much the correct software costs, you pay it because the consequences of not doing it perfectly are far too high.

Tip

Our discussion is not meant to be scholarship on the topic of software development methodology; instead, it is meant to show simple, basic processes that can bring a reasonable amount of control to a software development project. These steps are, to name a few, requirements gathering, specification, object analysis, database design, development iteration (code, unit test, repeat), and so on.

But most of us who write software do not deal with such consequences. Most of us are keeping track of purchases and payments. We're recording production data. We're tracking manifests and updating inventories. We are the great unwashed mass of MIS software developers. Here we, too, want to do it perfectly right. But every time we go to management and tell them how much it will cost and how long it will take, the little "mass layoff" vein throbs in their foreheads. We are always being told to do it faster and cheaper. And so we find ourselves, again and again, tilting at the windmill of quality.

So where does that leave us? When we go to management with the textbooks of software engineering, they either laugh or scowl. Clearly, the money people are not prepared to support the cost of doing it right. So what do you do? The best that you can. The one thing we can tell you for certain is that the formula for success is not "start writing code and trust to luck."

It is fair to say that even the minimal software development method should include the following steps:

• Requirements gathering
  
  
• Use case specification
  
  
• Class discovery and problem domain decomposition
  
  
• Technical requirements specification (architecturing)
  
  
• Testing
  
  
• Code and release management
  
  
• Production and operations support
  
  
• Bug and enhancement tracking
  
  

This list, when done in that order, has been referred to as the classic "waterfall" modeleach step is done in its entirety (or largely so) before proceeding on to the next step.

Or at least that's the ideal which programmers have often pursued.

The problem is that the process involves people, and people, especially those responsible for the requirements, a) are sometimes unimaginative and 2) keep changing their minds. They start out with some requirements, based on what they think they're going to need. But they just aren't imaginative enough to think of how terrible their system will be for the average user. They also keep changing their minds as to what they want.^[1]

^[1] Did you notice that we tried to hint at that ever-enjoyable mid-project shifting of requirements as we went from a) to 2), changing our numbering scheme midway? Minimal humor, admittedly, but if you've lived it, you understand.

The "iterative" approach has been tried as a way to address this problem. Rather than wait for all requirements to be spelled out perfectly, with the iterative approach you jump right in with what you do know, build that, but expect changes to come. The sooner you get a working product or prototype into the hands of the users, the sooner you'll get feedback on what works, what doesn't, and what is really wanted ("what works" is used here not in the testing sense, but in the usability sense).

Note, however, that in the iterative approach, one still gathers requirements, develops designs for the code and the tests, develops them, tests (and fixes) the code, and releases it. It's just that one does that on a much smaller and more rapid basis. You get something runnable sooner, and continue to modify it.

Some people will complain that this makes for more expensive rework, but we (and others) would disagree. You are refining the process. Your reworks are less expensive than if you went to the work of building the entire system only to have some key requirement(s) changethere can be a lot more "wasteage" there.

Be aware, however, that the iterative approach is not just "whipping the horses to run faster." It is not just the waterfall model run at high speed. Rather, it is using the early iterations of the product as a sort of a "living" requirements specification, one that you can show to people and that they can try out, in real-world scenarios, and on which they can give feedback. Don't expect to be able to compile complete requirements, but don't give up on talking to your end users and other stakeholders either. Requirements are still key to delivering a solution.

So with either approach, you'll start with requirements. Let's look at the art of requirements.