Articles

Please enter an article title, author, or keyword
Ping-Pong Programming: Enhance Your TDD and Pair Programming Practices

Team player Dave Hoover wants to share a software development practice he enjoys. It emerged from the practices of extreme programming as a competitive yet simultaneously collaborative practice. Dave has found that this practice promotes the flow of knowledge between software developers better than any other practice he has experienced. As you might have guessed from the title of this week's column, this practice is called ping-pong programming, or P3 for short.

Dave Hoover
Cook until Done

There's no shortage of advice on how you should model, design, test, build, and deploy your software project. Every author, trainer, and pundit will swear up and down that "they know the secret." They know how to build great software—they've done it before and all you have to do is follow their lead. Buy their software, read their books, buy their tools, attend their seminars, and do it just like they do it and you'll be a success, right? But somehow it doesn't seem to be that easy. In this column, the first in a series of articles that will explore the different avenues of software development, Andy Hunt and Dave Thomas, the Pragmatic Programmers, begin the journey by revealing that learning software development isn't as easy as the pros make it out to seem. Find out why these books and seminars work for them, but not always for the rest of us.

Andy Hunt Dave Thomas
The Goldilocks Parable: How Much Process Is Just Right

Getting process improvement "just right" is difficult. Go too far in the definition of processes, and it really does get too hot, with the heat coming from the people trying to use the processes. On the other hand process definitions that are too short to contain anything of value will leave users in the cold, and then there will be no improvement in the organization. Ed Weller states that a useful process improvement activity develops a set of process artifacts that meets the needs of the user. This helps the organization capture "tribal lore" and cast it into a set of process definitions that eliminates waste and improves time-to-market.

Ed Weller's picture Ed Weller
The GNU Make Standard Library

The GMSL contains functions for list and string manipulation, has a complete integer arithmetic library, and functions for data structures: there are GNU Make implementations of associative arrays and stacks. There are also built-in debugging facilities.

John Graham-Cumming's picture John Graham-Cumming
QA Preventing Failure Suffering for Success

One of the most valuable services a QA group provides is preventing failure. Ironically if the group succeeds at this, QA might find themselves unpopular or out of a job. Linda Hayes reveals how typical methods of measuring success can actually cause failure. Especially if success is achieved at the loser's expense.

Linda Hayes's picture Linda Hayes
Building an Independent Test Group

Are you attempting to start an independent test group or increase the scope and value of your present group? After building a highly effective thirty-person test group, Scott Eder reflects on the three major areas where he focused and the challenges he faced along the way. Take away sample work scope and purpose statements for your test group, and learn how to set realistic expectations at all levels within your organization. Find out the key processes that Scott implemented immediately to get his team off to a good start.

  • The foundations of an independent test group that is valued by your organization
  • Ways to build relationships with key stakeholders in order to foster a supportive environment for test and quality
  • How to create a sense of identity around which your test team can rally
Scott Eder
Test-Driven Development Isn't Testing

There's a common misconception that test-driven development is a testing technique when in fact it's a design technique. In this column, Jeff Patton explains this and how you might use your unit tests to explicitly guide and describe the design of your software.

Jeff Patton's picture Jeff Patton
TimeLine Postmortems

We should use project postmortems to improve our software process. But few teams do, and fewer teams reliably learn from project postmortems. You can introduce postmortems to your team easily with a timeline postmortem process. If you are already doing postmortems, a timeline-based approach may improve your results.
This process:

  • Takes little time (a few hours).
  • Has a high degree of software engineer acceptance.
  • Provides immediate feedback into your development process.
  • Increases team cohesion and rapport.
  • Reduces finger pointing.
Seth Morris
test automation Not Your Father's Test Automation

If you think that test automation is mostly about executing tests, then you're missing out on a big opportunity. Or rather, you're missing a lot of small opportunities adding up to a big one. Consider this: stop thinking about test automation as merely executing automated tests, stop thinking about test automation as something you need expensive tools for, and start discovering automation you can implement in a couple of days and usually with extremely inexpensive tools or tools you already have available. In this week's column, Danny Faught and James Bach suggest taking a more Agile approach to test automation.

James Bach's picture James Bach Danny R. Faught
Best Practices for Software Projects–Software Measurements

The key to efficient measurement is to first determine what goals you are trying to accomplish and what problems you are attacking. Many organizations waste time and money by measuring more things than are necessary. Before beginning a measurement strategy, determine the goals for your measurement.

Steve Miller

Pages

Upcoming Events

Apr 28
Jun 02
Sep 22
Oct 13