Communication Breakdown – Reports

All our server calls are logged in a monitoring database along with their execution time. We generate reports in order to spot any negative trends and identify where we could make efficiencies. Additionally, we need the server calls to be under 2 seconds to meet our contractual obligations.

Ryan got told to update the performance monitoring because some of the calls had generic names like “Add” and no one knew which server call it actually was because there were more than one feature with the same name. After his changes, all the logged server calls have more verbose names to easily identify where the code is e.g. “Configuration.Users.Add”. However, no one told the people who generate the reports that they need to modify their report-generating program to take into account the new format.

So when the new update went live, the reports were broken because they are searching for the wrong method names.

There was a “Major Incident” call with managers and support staff who all had no idea what was going on. I invited Ryan to the call to explain the change. Ryan pointed out “this should be in the release notes”. However, when they checked, all they stated was “Performance Monitoring should be more traceable” which is not only vague but doesn’t highlight an action for a team to take. 

There should have been some explicit communication between the teams, and the improvement agreed upon. It sounds like the feature was requested, but the team hadn’t known a developer was working on it and would have it ready for the upcoming release. Additionally, if there was some communication when the development started, maybe there were other problems that could have been fixed alongside this change for increased benefit.

Leave a comment