Chapter 6

Software Triage

In the fatalistically-named book Death March (Prentice Hall, 2003) Edward Yourdon describes the frequent and scary condition of software that is behind schedule, short on staff, over budget, or poorly designed. Yourdon’s theory is that when software projects get into this state, even the best modern software development methodologies will no longer apply. As you have learned in this chapter, many approaches to software development are built around formalized documents or taking a usercentered approach to design. In a project that’s already in “death march” mode, there simply isn’t time for these approaches.

The idea behind software triage is that when a project is already in a bad state, resources are scarce. Time is scarce, engineers are scarce, and money may be scarce. The main mental obstacle that managers and developers need to overcome when a project is way behind schedule is that it will be impossible to satisfy the original requirements in the allotted time. The task then becomes organizing remaining functionality into “must-have,” “should-have,” and “nice-to-have” lists.

Software triage is a daunting and delicate process. It often requires the leadership of a seasoned veteran of “death march” projects to make the tough decisions. For the engineer, the most important point is that in certain conditions, it may be necessary to throw familiar processes out the window (along with some existing code, unfortunately) to finish a project on time.

Building Your Own Process

and Methodology

There is one software development methodology that we wholeheartedly endorse, and it’s not necessarily any of the above. It’s unlikely that any book or engineering theory will perfectly match the needs of your project or organization. We recommend that you learn from as many approaches as you can and design your own process. Combining concepts from different approaches may be easier than you think. For example, RUP optionally supports an XP-like approach. Here are some tips for building the software-engineering process of your dreams.

Be Open to New Ideas

Some engineering techniques seem crazy at first or unlikely to work. Look at new innovations in software-engineering methodologies as a way to refine your existing process. Try things out when you can. If XP sounds intriguing, but you’re not sure if it will work in your organization, see if you can work it in slowly, taking a few of the principles at a time or trying it out with a smaller pilot project.

Bring New Ideas to the Table

Most likely, your engineering team is made up of people from varying backgrounds. You may have people who are veterans of startups, long-time consultants, recent graduates, and PhDs on your team. You all have a different set of experiences and your own ideas of how a software project should be run. Sometimes the best processes turn out to be a combination of the way things are typically done in these very different environments.

132

Maximizing Software-Engineering Methods

Recognize What Works and What Doesn’t Work

At the end of a project (or better yet, during), get the team together to evaluate the process. Sometimes there’s a major problem that nobody notices until the whole team stops to think about it. Perhaps there’s a problem that everybody knows about but nobody has discussed! Consider what isn’t working and see how those parts can be fixed. Some organizations require formal code reviews prior to any source code check-in. If code reviews are so long and boring that nobody does a good job, discuss code-reviewing techniques as a group. Also consider what is going well and see how those parts can be extended. For example, if maintaining the feature tasks as a group-editable Web site is working, maybe devote some time to making the Web site better.

Don’t Be a Renegade

Whether a process is mandated by your manager or custom-built by the team, it’s there for a reason.

If your process involves writing formal design documents, make sure you write them. If you think that the process is broken or too complex, see if you can talk to your manager about it. Don’t just avoid the process — it will come back to haunt you.

Summar y

This chapter has introduced you to several models and methodologies for the software process. There are certainly many other ways of building software, both formalized and informal. There probably isn’t a single correct method for developing software except the method that works for your team. The best way to find this method is to do your own research, learn what you can from various methods, talk to your peers about their experiences, and iterate on your process. Remember, the only metric that matters when examining a process methodology is how much it helps your team write code.

This chapter concludes the first part of the book, which has surveyed the landscape of software design. You have learned how to design a program, how to organize object relationships, how to make use of existing patterns and libraries, how to code effectively with others, and how to manage the process of developing software. Throughout the rest of the book, the design principles you have learned will be tied directly to C++. The next part of the book gets into the nitty-gritty details of writing professionalquality code in C++. Try not to forget the design lessons from the last few chapters as you get deep into the coding portion of the book — we put the design chapters first because we wanted to highlight their importance.

133

Coding with

Style

If you’re going to spend several hours each day in front of a keyboard writing code, you should take some pride in all that work. Writing code that gets the job done is only part of a programmer’s work. After all, anybody can learn the fundamentals of coding. It takes a true master to code with style.

This chapter explores the question of what makes good code. Along the way, you’ll see several approaches to C++ style. As you will discover, simply changing the style of code can make it appear very different. For example, C++ code written by Windows programmers often has its own style, using Windows conventions. It almost looks like a completely different language than C++ code written by Mac OS programmers. Exposure to several different styles will help you avoid that sinking feeling you get opening up a C++ source file that barely resembles the C++ you thought you knew.

The Impor tance of Looking Good

Writing code that is stylistically “good” takes time. You could probably whip together a program to parse an XML file into a plain text file in a couple of hours. Writing the same program with functional decomposition, adequate comments, and a clean structure would probably take days. Is it really worth it?

Thinking Ahead

How confident would you be in your code if a new programmer had to work with it a year from now? One of the authors, faced with a growing mess of Web application code, encouraged his team to think about a hypothetical intern who would be starting in a year. How would this poor intern ever get up to speed on the code base when there was no documentation and scary multiple-page