Daniel Wellman

Steve Berczuk is a software developer, writer, and experienced practitioner of software configuration management (SCM) and agile software development. He is a co-author of the book Software Configuration Management Patterns: Effective Teamwork, Practical Integration, contributed to the book 97 Things Every Programmer Should Know. Last year, he interviewed Dan Wellman about test-driven development. In this installment of From One Expert to Another, it’s Dan’s turn to interview Steve about the ins and outs of SCM.

Writing great software requires a lot of communication, and not just the client-to-server variety; person-to-person communication is crucial in a well-performing team. While it's easy to focus exclusively on improving our ability to communicate through the code we write, it's important to remember that building software is a communal experience: developers work with customers, testers, product owners, and other developers.

Here are some techniques and articles I use to reflect upon and improve my own communication skills:

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. 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.

Making Tests More Readable

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. I know - it's happened to me, especially with end-to-end Selenium tests.

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

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.

Automated unit tests verify that a component is working as expected.  They also serve as a way to understand how code works, though this doesn't always happen by reading tests.  Sometimes understanding comes from tweaking the tests to observe new failures, or rewriting the tests themselves. 

If getting together in a room with a small group of software professionals and having deep discussions about design and testing sounds like your idea of a good time, and you'll be in the Northeast next weekend, I've got the perfect conference for you: The Simple Design and Testing Conference.

OK, that may have sounded like a silly introduction, but I'm one of those people who think it sounds like a good time, and if you're still reading this, chances are you are too. Here's the scoop:

Good names make a design easy to understand, help clarify intent, and provide inspiration. But those perfect names can be a real struggle to discover. In his book Implementation Patterns, Kent Beck writes: "Finding just the right name is one of the most satisfying moments in programming."

Today I watched an old TED Talk by Dr. Hans Rosling entitled "Debunking third-world myths with the best stats you've ever seen."  If you haven't seen it yet, I recommend taking a moment to watch it - I've never seen statistics presented in such an engaging and entertaining fashion. In this talk, Dr. Rosling uses his fantastic visualization software to demonstrate the changing relation between the wealth and health of nations over several decades.

Selenium lets you automate testing a web application end-to-end using a real web browser. It's a great tool for smoke tests, especially when run periodically on a continuous integration server.

Providing only one way to do something may cause your colleagues, code readers, or API users to disagree with your choices. On the other hand, it prevents decision paralysis, which can be much worse than a disagreement.

There are a wealth of open source and commercial tools available to help us build software.  However, sometimes we get stuck using tools in ways that are not optimal for our project.  In these cases, investing some time to make the tools work for us can make substantial improvements in productivity.

Continuous Integration build tools are great: they help us ensure our product works after every commit, keep historical data and metrics, build our product for all target environments, and do many more useful things. But there's one key aspect that often gets overlooked: They're fun.