what-when-how
In Depth Tutorials and Information
15.4 STeP_INFramework[3]
In the popular opinion, the most important avenues of information and assistance
to the programmer who needs a little “boost” in their way of thinking about a cer-
tain programming situation are code, documentation, and various kinds of infor-
mation repositories (including, but not limited to, reuse repositories, discussion
archives, frequently asked question pages, etc.). However, possibly the most impor-
tant way to receive assistance is through the advice of another programmer. his
avenue is known as a peer programmer. Other programmers are often the most use-
ful way to get a fresh look at a problem or a situation in the collaborative software
development environment.
he problem with going to peer programmers for advice comes when the other
programmers have their own issues that they are dealing with, which is almost
always the case. If the “expert” programmers, as we will call them in this example,
are working on their own problems that have extensive environments of their own,
then they are most certainly engrossed in their work at that moment. he “ama-
teur” programmer, as we will call him in this example, gets stumped on his own
assignment and walks to the expert programmer's workspace. Once the interrup-
tion is initiated by the amateur programmer for the question, the expert program-
mer's concentration has been broken, and whether or not he answers the question,
the time will have to be taken to regain focus on the problem that he was working
on in the irst place. his is ineicient for the expert programmer, and could pos-
sibly have social consequences for the amateur programmer if hard feelings result
because of this setback.
A framework called the STeP_IN framework has been researched and created
to try and alleviate some of the problems that were described in the previous para-
graph. “It takes into consideration the social factor of treating peer programmers
as information resources, and employs mechanisms that ensure communications
between programmers that are not disruptive to the overall productivity as well
as social atmosphere of the team as a whole” [3]. It is a desperately needed design
that is attempted to be created in the STeP_IN framework. Imagine how much
time is wasted in collaborative software development teams just by interruptions
and having to get refocused on the task at hand. It has been estimated that 41%
of a programmer's time is taken up by communication that has to do with other
people's assignments and that have nothing to do with the original programmer's
own tasks [3]. his type of communication happens in an ad hoc fashion. It is
largely unscheduled, intense, and involves more people than it should. he STeP_
IN framework tries to alleviate this problem with certain design principles.
In order to successfully build a framework that addresses all the issues that have
been discussed so far, some basic principles had to be followed by the designers and
programmers themselves. For the design of the STeP_IN framework, the builders had
ive design principles that were used to guide them as they worked. he next few para-
graphs will discuss these five principles and their use in the STeP_IN framework.
