Better Software Magazine Articles

How Do You Build the Right Software Right?

Technical Editor Brian Lawrence explains his top-three list of things to do to deliver the right software right: risk-based planning, problem definition and modeling, and congruent leadership.
Brian Lawrence
June 26, 2002
Normal Processes

Using a sociological theory as his starting point, Technical Editor Brian Marick shows how sometimes systems can encourage local problems to blossom into system-wide catastrophes.
Brian Marick
June 26, 2002
Big Ball of Mud

Much of recent systems theory revolves around applying ideal software development patterns. Big Ball of Mud, in contrast, is for those of us who live and work in the real world, where most systems emerge haphazardly from minimally controlled chaos under constrained development conditions. Bar Biszick recommends and describes the Big Ball of Mud Web site.
Bar Biszick
June 26, 2002
How to Survive the Software Swamp

For a project to make long-term progress, it must build a platform of basic engineering practices. On this platform are set the ladders of advanced techniques that you select using risk analysis. Properly managed, these processes help you avoid falling back into the swamp whenever the project is under pressure.
Michael Deck
June 26, 2002
Finding Patterns in Software

"Patterns" have caught on among software designers, especially those working on object-oriented systems. More recently, patterns have been applied to organizational behavior, including patterns for organizing independent test groups. Brian Marick provides Web resources on the study of patterns.
Brian Marick
June 26, 2002
Quality Assurance and Testing

Brian Marick argues for using testers at the requirements analysis stage of a project. He says, "While QA is primarily about process, testing—my specialty—is about product. Whatever else a tester might do, she certainly eventually exercises the product with the aim of discovering problems a user might encounter. This essay is about that 'whatever else' the tester does."
Brian Marick
June 26, 2002
Tracking Severity: Assessing and Classifying the Impact of Issues (a.k.a. Defects)

How does one categorize Severity? Should you use numbers like 1, 2, 3; generic names like High, Medium, Low; or more specific names? A telephone switching system, for example, might use industry-specific categories such as "system issue," "line issue," or "call issue." Other environments, as we'll see in this article, tailor classification terms to meet their own functional needs.
Tim Dyes
June 26, 2002
Testing and Quality: Are You As Bored As I Am?

The next time someone says to you something like, "You can't test quality into a software project," you might reply, "Well, you can't manage it in either." There may be a pregnant pause, but perhaps it will lead to thoughtful discussions about testing and quality. At the very least, it'll make those twin subjects a whole lot less (shh!) Dullsville and boring!
Robert Glass
June 26, 2002
Anticipating Human Error

This article makes three points. First, errors happen. Second, systems can encourage errors. Third, a basic understanding of the kinds of errors humans make can help us design better systems. Here are some suggestions to help avert trouble.
 
Ramon M. Felciano
June 26, 2002
Packaged-Software Indigestion

Vendor reviews are a wonderful technique to taste before you swallow commercial, off-the-shelf software. They're also a great way to build a partnership with your business decision-makers on packaged-software projects, instead of being brought in late or left out completely. Here are some important things to consider when conducting a vendor review.
Eileen M. Strider
June 26, 2002

Pages

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.