Read Matt Nunn's companion article on using Visual Studio IntelliTrace for debugging here.
Writing code can be hard; building great solutions is even harder. Couple that with the fact that you probably don’t work alone, but that you have to collaborate with other developers, designers, testers, and project managers—and you have to get everything done within strict budget limits—and the task of building a great quality piece of software becomes "interesting" to say the least.
We all aspire to build great software but the reality is that, during the past couple of decades, most organizations have focused not on quality but on cost reduction, including driving down the cost of IT. And organizations have been fairly successful, but at what cost?
Also in the past two decades, we have not seen a significant upward trend in project success rates. In the past several years, according to the Standish Group’s Chaos Report (2009)[1], while projects regarded as outright failures have consistently trended down, projects regarded as challenged have edged up again. Only about 35 percent of projects are regarded as successful. Does this mean that the singular focus on cost reduction has effectively made it “cheaper to fail”? And if that's the case, have we really saved money?
Focus on Success
So, we're as successful as professional baseball players, but in most cases paid significantly less. If we want to be successful in the field of software engineering, we need to up our average significantly. Now is the time to put the cost reduction mentality behind us and to focus on successfully delivering the software we're asked to build. In the long run, that will be a much more efficient way of saving money.
To become successful, it's important to understand exactly what success looks like. Many projects classed as successful by an IT department (i.e., delivered on time, on budget, and with the specified features) may not be seen in the same light by the customer. At the end of the day, the only measure of success that matters is whether or not the customer (whoever that might be) is happy with the final product. This generally means that the product does what the customer wants (provides greater efficiency and effectiveness in their daily work) and is free of defects that detract from the software's effectiveness. Even though a project might meet the standard criteria for success, as judged by the IT department, for many reasons it might not be judged as successful from the customer's viewpoint. The customer's needs might somehow have changed since the inception of the project; the designed system might "work" but is considered "unusable" or any other myriad reasons that might make the project a technical success but a failure for the customer.