1. I did intend the first meaning. Actually, both make sense: minimize the number of developers creating new functionality and minimize the number working on infrastructure.

Now that you mentioned it, I can see how the term ‘infrastructure’ may be easily misinterpreted. I’m not sure what else to call it. I’m not keen on your suggestions. The term ‘Build Role’ or ‘Build Team’ may be appropriate, and is somewhat commonly used, but the activities I outlined as infrastructure tasks encompass more than just managing the build. Maybe ‘Software Admin Role’ is a more accurate description. They are administrative tasks in the context of a software development project (as opposed to general administrative tasks common to any business or project).

3, 4: I think I made a good case for why software administration tasks are important and necessary. Many of them can be justified from a productivity or risk-management basis. I think it is rare that external customers will be given enough visibility into a project to see these types of tasks. Usually the issue is a senior manager. :) It is funny that project management is another overhead activity that doesn’t produce functionality, yet senior management (or customers) expect it to be in place.

5. If your development team isn’t capable of maintaining necessary processes, fix the team instead of adding external police. You do need someone on the team responsible for maintaining necessary process - this is usually the lead / architect, but could be the person in the infrastructure role.

And thanks for the catch on my misspelling of Coplien - I’ve corrected the article.

“minimize the number of developers that are directly creating new functionality”

supposed to be this

“minimize the number of developers that are directly creating new infrastructure”?

You might consider changing the word “infrastructure” to “process” or “development process” or…, as infrastructure has somewhat different connotations than this subject matter, at least to me. Of course, I may just be interpreting things incorrectly.

This topic is awfully similar to the concept of technical debt, which could also be cast as process debt in many cases.

A few things to add to/challenge your cogitation on the topic:

1. Do you agree that developers are (implicitly) taught to disregard process by the mechanisms we use to teach developers (i.e. most curricula require at most 1 course on the “engineering” aspects of software development, while students hack out “good enough” code in many)? Are developers taught to be cowboys rather than to be disciplined, or is this just a rational response to circumstance? Do professionals want their paycheques less?

2. The optimal solution to this problem is not to write/create infrastructure at all. Choose the appropriate toolset (including processes) and only write/create infrastructure where it doesn’t exist or the cost/benefit of not having it is not there. Reuse before buy before build.

3. A lot of the things you class as infrastructure simply “shouldn’t” (a dangerous word) be missing from development, depending on its needed formality. Another class of solutions then would be to step back and see how much process you need before starting the (next) iteration. If the need has changed, then include the development of the process in the iteration,and share out the duties. Of course, selling your customer on this will be hard. Why should I pay you to learn to use your hammer?

4. Is it really neglectful not to consider infrastructure? Your customers only care about functionality. Should you give your customers “more” professionalism than they expect? Than they require? Than they will pay for (at this time)? How do you sell them the value of what you are doing? Or is this all just a “black ops” effort?

5. How do you make all this work if no one is policing the new processes? What magic makes this work, so you are not continually re-inventing?

6. Could the “sacrifice one person pattern” be renamed the “Donner Party” pattern? Or the “Mayan Altar” pattern? =;->

One final nit from a nit-wit: it’s “Coplien”.