I wrote an article for the September/October issue of Better Software Magazine: IDEs and Build Scripts in Harmony where I discuss how to use build tools, and IDEs while minimizing duplicate work and getting the benefits of both tools.

As usual, the editors did a great job selecting metaphorically appropriate art work, and there is lots of other good content in the issue, including an interesting commentary by Lee Copeland on testing, Scrum, and "testing sprints."

I won't repeat anything I say in the article (since I already said it), but I want to add some philosophical comments. The question of working in environments that use IDEs for development and integration builds that are driven by other tools is one that I care about because it involves some of the issues that often cause a lot of angst and discussion on development teams:

• Standardization and the effects of tools on individual and team productivity, and
• Repetition: having the same information in two places.

Many of these problems can be solved by tools that separate information appropriately. For example, dependency information in build scripts, formatting information in IDE settings, so you don't need to have duplicate configurations checked in. Or even having some sort of canonical way to describe formatting rules which you keep with the build scripts in a form that IDEs can leverage. This frees developers to use the tool that they are most accustomed to (and productive in), while maintaining the amount of standardization that helps teams be more productive.

I hope that you find the article interesting and thought-provoking.

---

Note: There was a production error that caused an old bio to show up in the print edition. I work at Humedica, not where the bio says .

This past week 97 Things Every Programmer Should Know was made available to the public. This project was driven by Kevlin Henney, who I know from the early Pattern Languages of Programming conferences, . The list of contributors contains many familiar names, and I'm honored to be among them.

My contributions are about the agility, deployment, and their intersection. They include:

• Own (and Refactor) the Build
• Deploy Early and Often
• Understand the Principles behind Practices, and
• Acknowledge (and Learn From) Failures
  

This project has contributions from many really interesting and insightful people. Maybe you already know everything on the lists, but you might get a fresh perspective by reading the contributions. You are very likely to start thinking.

On a related note, this past week, there was a conversation in my office between one of my colleagues who is a parent of a toddler, and one who isn't about why one works so hard to sound excited when talking to children about tasks.

You might say in an excited tone:

Being the proud (some who know me IRL might say too proud) parent of a 2-year, 9-month old boy, this got me thinking about why parents do this, and why it works so well. I suspect that the reasons are two-fold:

• Toddlers don't (yet) get the idea of consequences, but they get the idea of "fun" so framing something as fun and exciting is just the path of least resistance.
• Toddlers are wired to explore and learn, and every new thing is fun!

I'm realizing that, while as professionals, we need to do things for purely practical reasons learning about how to work better can (and perhaps should) be fun too. Seeing how toddlers learn makes me wonder how much of that joy of discovery we give up as we grow, and whether we need to lose it.

So as you read through the contributions in 97 Things, try to find something new and learn about it not just because it's something you should know, but because you enjoy programming, and because learning new things is fun!

As I was starting to prepare for a class I'm giving at the Software Test and Performance conference in Cambridge MA this October I looked over a paper Brad Appleton and I wrote in 1998 on branching patterns: Streamed Lines, and I started to think about the path from this paper to the SCM Patterns book. Streamed Lines describes a number of branching patterns and when it's appropriate to use each one. From time to time people still tell me or Brad that this is one of the better overviews of branching strategies they have seen.

The paper grew out of material we gathered in a workshop at ChiliPLoP 1998 in Wickenberg AZ. We organized the set of index cards, categorized by color-coded stickers into the paper we prepared for workshopping at PLoP 98 (which was the PLoP conference I was program chair for). Many steps later, with encouragement from John Vlissides, we submitted a book proposal and started working on Software Configuration Management Patterns. The SCM Patterns book says a lot less about branching than Streamed Lines, and more about how SCM and version management practices fit into a pragmatic and agile development environment. Given how the book morphed from the original branching patterns, there is still a place for the information in Streamed Lines.

Streamed Lines may be due for an update to take into account how things like distributed version management systems like git and Mercurial affect the cost of branching. Regardless of tools, branching can have costs relative to not-branching; just because something is easy to do, does not mean that it's the right thing to do, but newer tooling is worth considering as you develop an SCM strategy.

Have you read Streamed Lines? Does it need an update? What would you change about it? How much should tools affect the principles it describes?

An agile process such as Scrum is built on a number of both project management and engineering practices. The engineering practices support the project management practices and the project practices guide engineering decisions. While it takes more than the presence (or absence) of any one practice to cause your agile project to succeed or fail, some practices can drive your process in a powerful way. Sprint reviews are one practice that, when done with the right attitude, can help teams develop and maintain a good project rhythm.

An iteration process has mechanisms in place to help steer teams. Of all of the practices that support iteration, regular sprint reviews help teams and product owners get the feedback that they need to improve their performance. Reviews are also one practice that I've noticed that teams slack off on, especially when they are first starting out.

A common rationale for not having an iteration review are that there isn't enough to show. When the team is not making progress is the most important time to review progress with the product owner and evaluate how the project is doing and what needs to change. While the first review may be difficult, if everyone on the team is committed to a successful project, a review of less than successful sprint can have many positive consequences:

• The product owner many be more impressed my the progress than the team thought, freeing the team to take more ownership of their work.
  
• The product owner may be better able to understand that the backlog might be the wrong size as the team compares the results of sprint to the backlog, providing the team with the data it needs to have a more attainable backlog.
• The team may recognize things it can do to work more effectively.
  

It's important that everyone understand the reviews for what they are: brief, lightweight mechanisms for evaluating progress as a group and and understanding how to do improve. This means that it's OK for things to go wrong in a review. And the team should not spend a lot of time preparing or setting up environments. (With good engineering practices you should be able to build and deploy a "review version" quickly. If you can't considering prioritizing Deploying Early.)

As you identify issues it's also important to review progress on these issues at subsequent reviews. If you let them drop then the people at the review will come to understand that the review feedback is part of an empty exercise. It's OK to acknowledge that a review item wasn't acted upon, or is no longer necessary. But you should discuss each action from a review at the next one.

While this sounds easy, there are some challenges including establishing trust between the product owner and the team, and developing an understanding that they share the same goals. You need to be able to talk about what's not working, and figure out how to make it work, not just assign blame. If the team and the product owner is new to Scrum, and the project is new, you may have to start with a premise of trust. This is hard, but with the regular feedback of a review each sprint, the stakeholders will be able to readily evaluate everyone's dedication to the project.

It's very important to discuss what went well, preferably before covering what needs to be improved. (I tend to favor the attitude I learned from patterns writers workshops.)

Some suggestions for those struggling with agile:

• Have reviews at the end of each Sprint, using your backlog as an agenda.
• Show the work done in the simplest way possible.
• Collect feedback both on the work and the process, and identify things that went well and things to improve.
  
• Save the list of things to improve for the next review, and be sure to discuss them.
  

Agile methods are based on periodic feedback, and a review is a lightweight process to give feedback essential to a team. If your team is struggling with agile, have reviews each sprint, and try to understand what's working and what's not. The review will guide you to the most critical issues (technical and organizational) that you need to address.