What Happens During Software Maintenance? Anatomy of a Session – Part 2

If you followed Part 1 of this topic then you should understand that not only is it good to organize maintenance around changes rather than versions, but you might also see that doing so could provide a lot of information about how programmers go about their work.

The authors of the study mentioned in Part 1 did some detailed investigation of maintenance programming sessions.  They identified six types of sessions and used building maintenance as a metaphor (adapted here for RPG):

 

Session Type	Description
Decoration	The finest level of changes, such as changing individual statements in a subroutine
Painting	Adding subroutines or procedures to a program
Restoration	Performing refactoring
Masonry	Adding one or more programs or modules to the system
Architecture	Modification to the system’s structure – large scale additions of programs
City Planning	Major overhaul of the entire system

 

The authors then analyzed approximately 300 actual developer sessions and obtained the following results:

 

Session Type	Nbr of Sessions	Typical Duration
Decoration	204	Mostly < 1 hour
Painting	26	Mostly < 1 hour
Restoration	9	1-2 hours
Masonry	76	Mostly 2+ hours
Architecture	9	2-4+ hours
City Planning	none

Obviously these sessions counts are going to vary with the type of project, but the typical durations may represent a pattern that holds true for RPG developers as well, and perhaps the rough proportions of the session types are also true.  Managers may want to do independent validation of these results for their own situation.  Whatever the actual numbers, managers may want to use this information as input to 1) the work environment of developers and 2) their work schedules.

What else can be gained by analyzing maintenance sessions?  Several studies have shown that developers who are attempting to understand an unfamiliar program gain substantial knowledge by being able to understand past modifications.  The authors of this article note something pretty interesting I had not thought of before.  By being able to see the actual sequence of code changes a previous developer made it is possible to gain insight into the nature of those changes. This is because developers often start with core changes and graduate to more detailed and esoteric changes.  A later programmer can review this progression and gain understanding about which code is more fundamental to a feature.

I think that overall, one of the most important potential benefits to be gained by analyzing detailed session code changes, is that it introduces the opportunity for actual measurable process improvement on the part of individual developers.  The more experienced IT manager, or a more senior developer, can sit down with a programmer and review their actual thought process and suggest ways to improve the programmer’s maintenance process.  I think this holds potentially very valuable gains for software maintenance organizations.