Sometimes its hard to effectively share everything among all members of a group.  We have weekly meetings to review our projects and their status and we use project collaboration software but sometimes we simply get absorbed in our own projects and workload.

A great way to share information among team members is through fixing error logs.  For years, our developers were responsible for monitoring and fixing errors on their projects whenever they show up in the error logs.  A year ago I implemented a new system for fixing errors which keeps developers working on new code, and aware of other projects within the group.

We have a team of 5 web developers.  There is an automated nightly process that gathers our application server error logs and distributes them to the development group.  In the past each developer was tasked to look through the logs for errors pertaining to their code or areas of responsibility, and fix them.  This was boring and inefficient.  At times all 5 developers were sifting through the exact same logs, looking at the exact same errors.

Under the new system, the logs are assigned to one developer for the week.  First, they look for errors new projects deployed in the last week or two.  These errors are assigned to the developer or team responsible for that project using bug tracking software.  We use an open source solution written in ColdFusion by Ray Camden called LightHouse Pro.  It works great for us.

With those obvious errors out of the way the developer now looks for patterns in the error logs.  These patterns could be a reoccurring error across the servers, or one server prone to a specific issue.  They may also notice a pattern happening at a certain time of day.  This is one of the many benefits of having the same set of eyes assigned to the error logs for 5 business days in a row.  These errors are addressed first.  If fixing one piece of code can stop a pattern causing 100s of errors, this is your biggest bang for the buck, and most worth the time and effort.  Finally they look through remaining issues and try to work on something they are not familiar with.   A developer is expected to devote about 1.5 – 2 hours each morning of their assigned week.  On Friday, they issue a summary of errors fixed, assigned, and the remaining open errors.

Sometimes when someone in the group is so close to fixing an error, or has invested time and research to that issue, they keep ownership of that issue.  This is not required, but the system fosters a sense of ownership and pride in fixing a problem.

Before we started this system, our logs were a mess and considered a chore to work on.  When we began, our logs could have 1000+ errors in a 24 hour period, and take a full 2 hours each day.  One year later, our logs average a few hundred errors, and usually take an hour or less to work on.  Some weeks, there are only a handful of issues to fix.

The are many benefits to this system.  Everyone gets familiar with various areas of the site they would not normally have worked on.  Developers get familiar with other pieces of code on the site, and get a better sense of the big picture.  We are able to spot error patterns and also get a chance to work with well written code.  All this allows us to develop more effectively on our own projects.

Related posts:

1. Allow Developers To Make Mistakes Keep an environment where developers, and all employees for that...
2. deployment schedules are not effective Simply put, deploying code on a set schedule is not...
3. Using the Basecamp API to Create Project Reports A few months ago I wrote a post describing the...
4. Defining Roles Within a Development Team I am a big advocate of keeping teams lean and...
5. Keep Teams Lean Developing effectively starts with the team. Of course projects requirements,...

Related posts brought to you by Yet Another Related Posts Plugin.

Filed under:
code, dev team, experiences by bill breen