This is a software organizational / project management pattern that I have come across many times but never seen written, so here it is.
Context: You are managing a team (four or more people). The primary goal of your team is to develop new software functionality (either by creating a new product or enhancing an existing product). However, there are software development administrative activities that do not directly involve adding functionality but must be done (ideally because they contribute to the success of the project, or possibly because of organizational reasons). Examples of such activities include: maintaining automated builds, preparing deliveries, writing automated tests, investigating, fixing and tracking defects (customer support), updating documentation, upgrading software & libraries, configuration management, and general office administrative tasks.
Problem: How should these software administration activities be assigned to and performed by your team members?
Forces:
- We want to minimize the number of developers that are directly creating new functionality. Having more developers lowers the integrity of the design and increases the communication & coordination overhead.
- Developers generally prefer to develop new functionality rather than work on these activities.
- Pressure from management or customers for signs of progress can cause a general focus on developing new functionality which can lead to a conscious or unconscious neglect of these activities.
AntiPattern Solutions: There are several different ’solutions’ to this problem that are antipatterns: these approaches are quite common in the industry yet fail to resolve the forces in a satisfactory manner.
- Ad-Hoc: The project manager fails to plan for software administration activities, so they are assigned on an ad-hoc basis. This tends to serve as interruptions for the developers given the assignment, which reduces their efficiency and typically impacts the schedule.
- Neglect: Software administration activities are left undone in favor of developing new functionality. This can happen because the project manager does not feel that the activities are important, or is under so much pressure that they feel they don’t have the time to do anything but develop software. Typically this leads to one or more problems occurring (i.e. loss of changes due to poor configuration management, large number of defects) which negatively impacts progress and may jeopardize the project (i.e. too many defects found during customer acceptance testing).
Solution: The solution is to define a software administration role. Assign one or more people to this role full-time. The number of people will depend on the size of the team and the amount of work involving these activities. The role can be a good learning opportunity for those not ready to develop actual production code. Developers new to the project or junior developers lacking certain skills can be good candidates for assigning to this role. If your project is large enough, you can form a separate software administration team. If such a team consists of mainly inexperienced staff, then a fairly experienced team lead should be placed in charge in order to ensure the team functions properly.
You should consider occasionally swapping team members from application development to software administration and vice-versa. This helps deal with a couple of problems:
- Bad feelings between teams: if things go wrong with items like the build or version control, or if it changes (even if the change is for a good reason), the application developers will tend to start to resent the administration developers. The application developers may make unrealistic demands (i.e. Act like typical IT customers) of the administration developers which can lead to resentment in the other direction. Swapping people between the roles helps them to appreciate the other side.
- Software administration tasks are typically perceived as less enjoyable than new development tasks. By providing the opportunity to move to development, developers can more easily tolerate time spent on these tasks.
Resulting Context: There are fewer people directly involved in application development, therefore reducing the communication and coordination overhead. Having people directly responsible for software administration activities will help ensure that these activities get done in a timely and proactive manner. If higher management does not appreciate the importance of these activities to the project’s success, they may try to reallocate people who you have assigned to the software admin role.
Known Uses: I was inspired to write this pattern by an article by Cara Taber and Martin Fowler titled “An Iteration in the Life of an XP Project.” (Cutter IT Journal, Volume XII, No. 11, Nov 2000) which describes using XP on a large team. The approximately 26 developers are split into two equally-sized teams: one team doing the main development, and a SWAT team that handles activities such as bug fixes, build process, testing automation, and performance tuning. I have heard of two other cases where different managers have formed explicit software administration teams.
Related Patterns: Two related patterns from Jim Coplien’s organizational pattern language are the Team Per Task pattern and the Sacrifice One Person pattern.
If you find this article helpful, please make a donation.
Share this article:
Given your overall context, is this sentence fragment
“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”.
Thanks for the thoughtful comment - I’ll respond to some of the points:
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.
I decided to rename the pattern as the Software Administration Role pattern, and updated the article (and page URL) accordingly.