In designing and developing software, it’s usually cheaper to prevent problems from ever occurring (by making a decision at design-time) rather than patching them as they happen (by a last-minute fix after deployment). It’s cheaper (and substantially less stressful) to design a system to handle thousands of concurrent users rather than trying to diagnose and fix a system that mysteriously breaks in production under heavy load. But detecting problems in real-time is a useful skill in many professions, including one as different as recording audio books. 

There has been a lot of recent discussion on Twitter about the use of mocking frameworks and writing readable tests. Here is a roundup of some of the recent blogs on the subject.

In “Growing Object Oriented Software Guided By Tests”, Steve Freeman and Nat Pryce talk about the dangers of tests that occasionally fail, otherwise known as flickering tests. These failures can cause teams to start seeing these failures as false positives, and distrust their build results.

There has been a lot of discussion about this topic recently.

At the Agile 2009 Conference, the LiveAid lab created an iPhone application to enable people to donate to the Mano a Mano charitable organization. This lab was an opportunity for participants to learn something new, practice their craft, donate their time to a worthy cause, and meet other folks. By the end of the conference, the application was working and had collected over $10,000 in donations.

Volunteering offers an opportunity to practice our craft and give something back to the community.

We spend our time at work reflecting on our team's progress. Yet it’s easy to forget to follow these same self-evaluation processes for our own professional development.

Agile software development practices have been finding their way in to various industries; finance, education, government, and even games.

As programmers, we’re constantly working to improve and evolve our designs. Refactoring helps us take an evolving code base and make it look like the code was designed for today’s problems right from the start. And hey, it can actually be fun!

But it’s not easy. It can be difficult to make small steps in a tricky bit of code, hard to figure out how to fix a particular code smell, and hard to know when you’re done. 

Practice helps us build our skills and recognize patterns in code.  Read on for some ways to practice refactoring.

A computer is really, really good at identifying the differences between two chunks of text.  Use the Gold Master pattern in circumstances where you need to verify that there are no unexpected changes.

No, you won’t need an oracle or a tricked-out DeLorean to peer into the future. It turns out you’re already using a great tool for simulating time travel.

The life of a software product is a continual stream of feature additions, enhancements, and even removals. But a great product doesn’t (usually) outshine its competitors because of the sheer number of features, it’s because those features are really useful or work well together. It’s a difficult balance that requires a lot of iteration and experimentation.

For advice on tackling this difficult problem, you might try looking to Batman.