ArticlePDF Available

Abstract

This article presents a technical opinion in the case of collaborative programming for a large, complex system, in which two programmers are working jointly on the same algorithm and code. A field experiment was conducted using experienced programmers who worked on a challenging problem important to their organization, in their own environments, and with their own equipment. Findings revealed that all the teams outperformed the individual programmers, enjoyed the problem-solving process more, and had greater confidence in their solutions. Several aspects of this experiment make the results significant. First, there may be a tendency to dismiss results using small groups. Questions may arise at the value of these results if the collaborators do not perform twice as well as individuals, at least in the amount of time spent. The article concludes that the crunch-time information systems development will demand innovative ways to produce high-quality systems in a short time, with companies increasingly introducing new products. This rare experimental research is phenomenon considering the luxury of using collaborative programming while many companies are experiencing shortages of experienced programmer/analysts.
COMMUNICATIONS OF THE ACM March 1998/Vol. 41, No. 3 105
Team programming usually
means coordinating efforts
of individual programmers
who divide up the programming
tasks for a large, complex system.
Collaborative programming is
used here to mean two program-
mers working jointly on the
same algorithm and code. Previ-
ous research indicates that stu-
dent programmers working
collaboratively outperformed
individual programmers. A fol-
low-up field experiment was con-
ducted using experienced
programmers who worked on a
challenging problem important
to their organization, in their
own environments, and with
their own equipment. To the sur-
prise of the managers and partici-
pants, all the teams outperformed
the individual programmers,
enjoyed the problem-solving
process more, and had greater
confidence in their solutions.
Description of the
Experiment
“Effective problem-solving per-
formance” is defined in terms of
(a) the readability of the pro-
posed solution, that is, the
degree to which the problem-
solving strategy could be deter-
mined from the subject’s work;
and (b) the functionality of the
proposed solution, that is, the
degree to which the strategy
accomplishes the objectives
stated in the problem descrip-
tion. The variables READABIL-
ITY and FUNCTIONALITY
were defined accordingly. Read-
ability is a component of overall
score since it is possible for a
subject to use a reasonable strat-
egy and to use programming lan-
guage structures appropriately
and yet fail to solve the problem
(in the sense of generating the
correct output). In such cases, the
programmer may have misinter-
preted the problem description
or overlooked a critical compo-
nent. Overall success on the
problem-solving effort is mea-
sured by a variable SCORE,
which is a simple sum of compo-
nent variables READABILITY
and FUNCTIONALITY. Based
on previous results, four predic-
tions were made:
1. Programmers working in pairs
will produce more readable
and functional solutions to a
programming problem than
will programmers working
alone.
2. Groups will take less time on
average to solve the problem
than individuals working
alone.
3. Programmers working in pairs
will express higher levels of
confidence about their work
(CONFID) and enjoyment of
the process (ENJOY) immedi-
ately following the problem-
solving session than will
programmers working alone.
(Positive feelings about the
problem-solving process can
affect performance. These feel-
ings were assessed immedi-
ately following the
problem-solving session by a
two-item questionnaire.)
4. Programmers with more years
of experience will perform bet-
ter than programmers with
fewer years of experience.
Aside from the pairing, condi-
tions and materials used in the
experiment were the same for
both experimental (teams) and
control (individuals) groups.
These subjects were 15 full-time
system programmers from a pro-
gram trading firm working on
system maintenance of three
Unix networks and a large data-
base running Sybase. They used
The Case for
Collaborative Programming
John T. Nosek
106 March 1998/Vol. 41, No. 3 COMMUNICATIONS OF THE ACM
the X-window system with the C
language. The firm uses a very
large database to get information
on program trading. The subjects
were asked to write a script that
performs a database consistency
check (DBCC) with the output
for errors to be written to a file.
If no errors are found then the
script should
write to the out-
put file saying
that no errors
were encoun-
tered. Also, the
script should dis-
play on the
screen whether
the results of this
output are to be
mailed to all the
system adminis-
trators. To evaluate
the READ-
ABILITY vari-
able, the subjects
were asked to
properly com-
ment on each of the processes
within the script they were pro-
gramming. None of the subjects
had worked on this kind of prob-
lem before. DBCC checks are
considered so critical to the orga-
nization’s success and generally
beyond the skill of in-house pro-
grammers that outside consul-
tants are usually hired to perform
them. The subjects in the experi-
mental paired groups and the
control group of individuals were
randomly assigned using a set of
randomly generated numbers. All
subjects were given 45 minutes
to solve the problem.
During the problem-solving
phase, the pairs were allowed to
communicate freely with their
randomly assigned partner; sub-
jects working alone were asked to
work without any communica-
tion. To solve the problem, all
subjects used Sun Microsystems
SPARCstations, equipment with
which they were very familiar.
The post-treatment questionnaire
was given to each subject after he
or she had handed in all the
problem-solving materials. A
stopwatch was used to time each
group and individual. Each set of
materials was evaluated on the
degree to which it solved the
problem (FUNCTIONALITY)
and on the readability of the
solution (READABILITY).
The functionality score was
obtained as a sum of three parts
corresponding to the three out-
put requirements stipulated in
the problem description. The
READABILITY scores could
range between 0 to 2. READ-
ABILITY was assigned 0 for an
entirely unreadable solution, 2
for an entirely readable solution,
and 1 otherwise. FUNCTION-
ALITY scores ranged from 0 for
a solution which did not achieve
the goal at all, to 6 if the solu-
tion achieved the goal entirely.
With the exception of time, per-
formance measurements were the
average scores of two separate
graders. Overall SCORE was
obtained by summing READ-
ABILITY and FUNCTIONALITY,
a perfect overall score being 8.
Results
The t-test, a statisti-
cal technique
designed to compare
the means of two
small samples, was
used. The two-sided
t-test, which looks at
the ends of both
sides of a flattened
normal distribution
curve, was used
because this proce-
dure tests for results
that are in the pre-
dicted as well as in
the opposite direc-
tion expected, the
standard procedure in this kind
of experiment. The significance
level for all tests was set so that
the probability was less than 1 in
20 that results were due to
chance. Two graders separately
evaluated the problem solutions
with inter-grader reliability of
over 90%.
The table presents the means
and results of the two-sided t test
for performance and satisfaction
measurements, the test created
for small sample sizes. Predic-
tions 1 and 3 were supported.
For example, groups outper-
formed individuals, enjoyed their
collaborative problem-solving
process more, and were more
confident in their solutions. In
fact, all groups outperformed
Performance
Scores:
READABILITY
FUNCTIONALITY
SCORE
TIME (minutes)
Satisfaction
Measures:
CONFID
ENJOY
n = 5
1.40 (0.894)
4.20 (1.788)
5.60 (2.607)
42.60 (3.361)
n = 5
3.80 (2.049)
4.00 (1.870)
n = 5
2.00 (0.000)
5.60 (0.547)*
7.60 (0.547)*
30.20 (1.923)
n = 10
6.50 (0.500)*
6.60 (0.418)*
Comparison of Individual and Team Measurements
Variable
Control Group
(Individuals)
mean (st. dev.)
Experimental Group
(Teams)
mean (st. dev.)
*less than 1 in 20 that results are due to chance
Technical Opinion
individuals. Although the aver-
age time for completion was
more than 12 minutes (41%)
longer for individuals, prediction
2 was not statistically supported
because there is more than a 1 in
20 chance that this is due to
chance. Prediction 4 was sup-
ported. Experience and problem
scores were highly correlated for
both the control (73.5%) and the
experimental (87.2%) groups.
Discussion
The results provide additional
evidence that collaboration
improves the problem-solving
process. Several aspects of this
experiment make the results sig-
nificant. First, there may be a
tendency to dismiss results using
small groups. However, it is rare,
if not impossible, to obtain the
time and cooperation of experi-
enced programmers to perform
the identical task. Much experi-
mental research is automatically
dismissed because it is done with
students, who are more plentiful
but who do not possess the skills
and knowledge of experienced
programmers. The subjects of
this experiment were experienced
programmers, working on an
important, challenging problem,
in a natural setting. Second,
because of the inherent bias
against small samples in statisti-
cal models, Miller [2]emphasizes
that a small sample, with a prob-
ability of only 1 in 20 that
results were due to chance, may
be far more striking than results
from larger sample sizes that have
the same or lower probability.
Third, this experiment was an
extension of previous ones, not
just a one-time event.
The results are consistent with
previous experiments that used
simpler, canned problems. The
qualitative data also provides
some interesting insights. The
majority of programmers were
somewhat skeptical of the value
of collaboration in working on
the same algorithm/program
module and thought that the
process would not be enjoyable.
However, as the results indicate,
and supported by their com-
ments, collaboration did improve
their performance and they
enjoyed their efforts. One pro-
gramming pair experienced a
“qualitative jump” as compared
to the other groups and individu-
als in the experiment. To the
amazement of the manager, their
programming solution was better
than previous scripts written for
the company. It is costly to run
these scripts and efficiently writ-
ten scripts are considered so diffi-
cult to create that the company
hires expert outside consultants
to write them. However, the
script written by this program-
ming team was twice as efficient
as previously purchased scripts.
Some may question the
value of these results if the
collaborators do not per-
form “twice” as well as individu-
als, at least in the amount of time
spent. For instance, if the collab-
orators did not perform the task
in half the time it takes an indi-
vidual, it would still be more
expensive to employ two pro-
grammers. However, there are at
least two scenarios where some
improved performance over what
is expected or possible by a single
programmer may be the goal: (1)
speeding up development and (2)
improving software quality.
In the first case, bringing a
product to market a month ear-
lier can mean a competitive edge,
or gaining, in some cases, even
survival. As organizations find it
increasingly difficult to produce
current products more efficiently,
they are escalating the number of
new products to market, where
the profit margins are greater.
According to the Product Devel-
opment and Management Associ-
ation, new products are expected
to account for 37% of total sales
by 2000, up from 28% for the
five years that ended in 1995 [3].
A reduced product life cycle,
combined with an increased
informational component of the
product, is a growing, critical
problem for information systems
departments:
“Crunch mode is not a matter
of opportunity—it’s a matter of
survival.… The ability to get
working software quickly into
the hands of users will be charac-
teristic of successful data-process-
ing organizations for the
foreseeable future. Groups that
can produce and install software
systems within tight time frames
will prosper. Those [that]
can’t will fail and, in some cases,
they will bring the enterprises of
which they are a part down with
them. Fast response to changing
information-processing require-
ments is a necessity in today’s
world.” [1]
Additionally, while there was
more than a 1 in 20 probability
that the time saved by groups
was due to chance, the groups
completed the task 40% more
quickly and more effectively. The
collaborative programmers pro-
COMMUNICATIONS OF THE ACM March 1998/Vol. 41, No. 3 107
duced better algorithms and code
in less time. As we all know,
poorly written code completed
quickly may in fact cause greater
delays in the overall development
and implementation time. Prior
to this experiment, standard
practice would limit the
resources that could be brought
to bear to speed up the process.
For example, additional program-
mers could be assigned to addi-
tional program modules.
However, programmers would
generally not be assigned to the
same program modules.
Group support technologies
may be employed to marshal pro-
grammer resources wherever they
exist to work on critical, time-
pressing systems.
The second scenario has to do
with improved quality in soft-
ware writing and testing. We
group together pseudocoding,
programming, and human-test-
ing procedures, such as struc-
tured walk-throughs, because
they involve closely related cog-
nitive skills, where programming
is the syntactical translation of
pseudocode into specific com-
puter languages and human-test-
ing procedures validate the
process. As program generators
and packages become more
prevalent, the greatest value
added by the programmer/analyst
may be as a contributor to team
development of innovative algo-
rithms and novel implementa-
tions of process and data models.
Conclusion
With companies increasingly
introducing new products,
crunch-time information systems
development will demand innov-
ative ways to produce high-qual-
ity systems in a short time. Pro-
fessional collaborative program-
mers who jointly developed
algorithms and code outper-
formed individual programmers
in this real-world field experi-
ment, a rarity in experimental
research. While the number of
subjects was small, this experi-
ment is not a single experiment,
but builds upon previous experi-
mental studies done with student
collaborative programmers. Some
may wonder at the luxury of
using collaborative programming
while many companies are expe-
riencing shortages of experienced
programmer/analysts. However,
the results raise intriguing ques-
tions. Can two average or less-
experienced workers collaborate
to perform tasks that may be too
challenging for each one alone?
Can a company bring a product
to market substantially earlier by
using collaborative program-
ming? Can collaborative pro-
gramming using worldwide
commodity programming
resources offer a competitive
edge?
References
1. Abdel-Hamid, T.K. Investigating the
cost/schedule trade-off in software develop-
ment. IEEE Software (Jan. 1990), 97–105.
2. Miller, R.G. Beyond Anova, Basics of Applied
Statistics. John Wiley and Sons, New York,
1986.
3. Warner, S. A dreamer finds the Expertise to
Develop an Idea. The Philadelphia Inquirer,
Philadelphia, Penn., Dec. 1, 1996, D1.
John T. Nosek (nosek@cis.temple.edu)
is a professor in the Computer and
Information Sciences Department at
Temple University, Philadelphia.
© ACM 0002-0782/98/0300 $3.50
c
108 March 1998/Vol. 41, No. 3 COMMUNICATIONS OF THE ACM
Technical Opinion
CALL FOR 1999
ACM FELLOWS NOMINATIONS
The designation “ACM Fellow” may be
conferred upon those ACM Members
who have distinguished themselves by
outstanding technical and professional
achievements in information technology,
who are current voting members of ACM
and have been voting members for the
preceding five years. Any voting member
of ACM may nominate another member
for this distinction. Nominations must
be received by the ACM Fellows Com-
mittee no later than August 1 of each
year and must be delivered to the Com-
mittee on forms provided for this purpose
(see below).
Nomination information organized by a
principal nominator includes:
1) excerpts from the candidate’s current
curriculum vitae, listing selected pub-
lications, patents, technical achieve-
ments, honors, and other awards.
2) a description of the work of the nomi-
nee, drawing attention to the contribu-
tions which merit designation as Fellow.
3) supporting endorsements from five
ACM Members.
ACM Fellows nomination forms and
endorsement forms may be obtained
from ACM by writing to:
ACM Fellows Nomination Committee
ACM Headquarters 1515 Broadway
New York, New York 10036-5701
nominate-fellows@acm.org
The forms can also be accessed on the
following:
http://www.acm.org/awards/fellows/
nomination_packet.html
Completed forms should be sent by
August 1, 1998
to one of the following:
ACM Fellows Committee
ACM Headquarters
1515 Broadway
New York, New York 10036-5701, USA
or
nominate-fellows@acm.org
or
+1-212-869-0824 - fax
ACM Fellows
... In recent years, some experts have proposed the concept of "collaborative programming", which can be simply defined as a teaching method that allows students to work in teams to complete programming projects. Collaborative programming aims to enable students to achieve higher programming quality (De Faria E. et al., 2006), faster programming speed (Nosek, 1998;Williams et al., 2000), fewer programming errors (Nosek, 1998), and improve their self-efficacy in problem solving through mutual collaboration (Denner et al., 2014). At present, collaborative programming has been widely used in computer education, and many researchers have conducted experimental studies on collaborative programming, proving that it has certain advantages in computer learning (Denner et al., 2014;Beck & Chizhik, 2013;Williams et al., 2002;De Faria E. et al., 2006;Nosek, 1998). ...
... In recent years, some experts have proposed the concept of "collaborative programming", which can be simply defined as a teaching method that allows students to work in teams to complete programming projects. Collaborative programming aims to enable students to achieve higher programming quality (De Faria E. et al., 2006), faster programming speed (Nosek, 1998;Williams et al., 2000), fewer programming errors (Nosek, 1998), and improve their self-efficacy in problem solving through mutual collaboration (Denner et al., 2014). At present, collaborative programming has been widely used in computer education, and many researchers have conducted experimental studies on collaborative programming, proving that it has certain advantages in computer learning (Denner et al., 2014;Beck & Chizhik, 2013;Williams et al., 2002;De Faria E. et al., 2006;Nosek, 1998). ...
... Collaborative programming aims to enable students to achieve higher programming quality (De Faria E. et al., 2006), faster programming speed (Nosek, 1998;Williams et al., 2000), fewer programming errors (Nosek, 1998), and improve their self-efficacy in problem solving through mutual collaboration (Denner et al., 2014). At present, collaborative programming has been widely used in computer education, and many researchers have conducted experimental studies on collaborative programming, proving that it has certain advantages in computer learning (Denner et al., 2014;Beck & Chizhik, 2013;Williams et al., 2002;De Faria E. et al., 2006;Nosek, 1998). ...
Article
Full-text available
Collaborative programming is being increasingly used to overcome the difficulties of the individual programming process. In this study, we investigated the effect of collaborative perception on cognitive engagement and learning outcomes in collaborative programming. We used a quasi-experimental research to determine the differences in cognitive engagement and learning outcomes of three groups with different levels of collaborative perception. The findings highlight several important conclusions. First, there were significant differences in cognitive engagement and learning outcomes across collaborative perception groups. Students with high levels of collaborative perception demonstrate more comprehensive and diverse cognitive engagement, resulting in higher learning outcomes compared to those with lower perception. Second, students in the low collaborative perception group had more Clarification-Elaboration cognitive connections, and students in the high collaborative perception group had stronger Clarification-Positioning and Clarification-Verification cognitive connections. Third, collaborative perception positively moderated the relationship between cognitive engagement and learning outcomes. In particular, three cognitive engagement, Clarification, Elaboration, and Positioning, had a greater impact on performance when moderated by collaborative perceptions. These findings have practical implications for educators and course designers, emphasizing the importance of considering students' collaborative perception when forming groups and promoting effective collaborative programming.
... Pair programming has been accepted in more and more fields because of the higher code quality created and less time spent compared with solo programming (Nosek, 1998;Williams, Kessler, Cunningham, and Jeffries, 2000;McDowell, Werner, Bullock, and Fernald, 2002;Muller, 2004). Furthermore, it could improve programmers' and learners' programming experience and their cooperative consciousness (Muller, 2004;Nagappan, Williams, Ferzli, Wieve, Yang, Miller, and Balik, 2003). ...
... In the previous researches which focused on introductory programming courses, it has been proved that pair programming is more outperformed than solo programming. Pair teams were found to usually develop the program and software with higher quality (Nosek, 1998;Williams, Kessler, Cunningham, and Jeffries, 2000;McDowell, Werner, Bullock, and Fernald, 2002), but the time spent was shorter than individual programmers (Williams, Kessler, Cunningham, and Jeffries, 2000). Programmers worked in pair were more self-sufficient, generally performed significantly better on projects and exams (McDowell, Werner, Bullock, and Fernald, 2002;Nagappan, Williams, Ferzli, Wieve, Yang, Miller, and Balik, 2003). ...
Article
Pair programming , a programming technique conducted by two programmers work together at one work station, has been adopted for learning programming. Although it is known to be effective in various aspects, micro observation of the learning activity, collaboration, has yet to be conducted in relation to the outcome. In this study, behavior in pair programming learning was investigated in terms of verbal communication and programming action, and was compared in relation to the success of problem-solving. Findings are that, in the successful cases, 1) the learners took programming actions more frequently, and 2) the learners took more programming actions immediately after the dialogue. From this, it is suggested that closely-knit dialogue and action can be an indicator of successful problem-solving, and the findings can be applied to a collaborative learning support systems.
... In lab and group work settings, Dombrovskaia and Barrera (2018) further demonstrated that collaborative programming enhances student performance, narrowing exam performance gaps over time. Additionally, collaborative programming has been shown to increase enjoyment and confidence compared to individual efforts (Nosek, 1998), while also improving learners' attitudes and motivation toward programming Buitrago-Flórez et al., 2017). ...
Article
Real-time collaborative programming (RCP), which allows multiple programmers to work concurrently on the same codebase with changes instantly visible to all participants, has garnered considerable popularity in higher education. Despite this trend, little work has rigorously examined how undergraduates engage in collaborative programming when using RCP. This study utilized a quasi-experimental design to investigate the impact of RCP on undergraduates’ programming knowledge and skills, behaviors, and attitudes toward collaboration. Eighty-two participants were randomly assigned to either the RCP group or the Traditional Collaborative Programming (TCP) group. The data analysis yielded noteworthy findings. First, RCP significantly improved learners’ problem-solving skills and led to higher knowledge test scores compared to TCP. Second, there were no significant differences in attitudes toward collaboration between the two groups. Third, analysis of programming behaviors indicated that the RCP group exhibited more efficient coding practices, including producing a greater volume of code and executing it more successfully. Additionally, the RCP group’s code-testing activities were predominantly concentrated at the first half of the class sessions. Based on the empirical research results, three major pedagogical implications were proposed. These findings highlight the benefits of integrating RCP into programming education and suggest avenues for future research into collaborative learning dynamics.
... Belbin [7] szerint a csoportszerepek ¶ es a szinergi ¶ ak kÄ ozÄ ott kapcsolat¯gyelhet} o meg. KÄ ozelebb kerÄ ulve a szoftverprojektek menedzsel ¶ es ¶ ehez tov ¶ abbi tanulm ¶ anyok [15,48,52] vizsg ¶ alt ¶ ak a szem ¶ elyis ¶ egt ¶ ³pusok ¶ es a p ¶ aros programoz ¶ as sikeress ¶ ege kÄ ozÄ otti kapcsolatot [40]. Belbin azt javasolta, hogy a csoportokban l ¶ ev} o kÄ ulÄ onbÄ oz} o feladatokat ell ¶ at ¶ o csoporttagokat v ¶ a-lasszuk sz ¶ et ¶ ugynevezett Belbin-f ¶ ele csoportszerepekre, ¶ es rendezzÄ uk } oket h ¶ armas csoportokba vagy tri ¶ adokba [7,8]. ...
Article
Napjainkban a legtöbb szoftverprojekt rugalmas, például agilis, extrém vagy hibrid környezetben valósul meg. Ezekben a környezetekben a projektekben szereplő tevékenységek végrehajtásához prioritásokat rendelnek. A kötött végrehajtási struktúra helyett pedig általában a rugalmas végrehajtás a jellemző, ahol a tevékenységek végrehajtási sorrendje a projekt előrehaladtával változhat. Ráadásul a rugalmas megközelítéseket egyre inkább alkalmazzák nem szoftverprojektek esetén is. A legtöbb szoftverprojekt-ütemezési probléma (angolul: Software Project Scheduling Problem, SPSP), amely egy tágabb problémakör, a projektütemezési probléma (Project Scheduling Problem, PSP) része, fix projektvégrehajtási struktúrát feltételez. Ha ezeket a hagyományos módszereket használjuk, nem tudjuk modellezni és így megérteni, hogy bizonyos rugalmas, pl. agilis irányelvek miért elengedhetetlenek, és hogyan segítik a projektmenedzsmentet. Kutatásunk bemutatja, hogy egy mátrixalapú projekttervezési megközelítés hogyan modellezheti a csoportszerepeket és a munkavállalók közötti szinergiákat. A szinergiaalapú szoftverprojekt-ütemezés problémáját kibővítve a tanulmány bemutatja az autonóm csoportszerepek kiválasztásának hatásait a DISC viselkedéstípusokon keresztül. A javasolt modell képes kezelni (1) a rugalmas projekteket, (2) a munkavállalók közötti szinergiákat és (3) a kemény és a puha készségek (soft and hard skill) közötti különbséget. Tanulmányunk hidat képez az operációkutatási modellek, a csoportszerepek modellezése, valamint a rugalmas projektütemezési megközelítések között. A javasolt módszert egy valós vállalati esettanulmányon keresztül értékeljük. Az eredményeket összehasonlítjuk a meglévő, nem szinergiaalapú projektütemezési módszerekkel. Vizsgálataink eredménye nemcsak azt mutatja meg, hogy a munkavállalók közötti pozitív szinergia csökkentheti a projekt átfutási idejét, hanem azt is, hogy a legjobb megoldást mely csoportszerep kiválasztása adja.
... An intentional application of CSCL to improve student engagement and learning outcomes is pair programming. Pair programming is a software development technique where two individuals work on the same code simultaneously; one as a driver who types code and the other a navigator who reviews, discusses, or dictates code [23], [24], [25]. Implementation in programming and computer science courses showed improved learning outcomes via improved assignments and final exam grades [26], [27], coding quality and achievement [28], and increased student attendance [29]. ...
Article
Remote pair programming is widely used in software development, but no research has examined how race affects these interactions between developers. We embarked on this study due to the historical under representation of Black developers in the tech industry, with White developers comprising the majority. Our study involved 24 experienced developers, forming 12 gender-balanced same- and mixed-race pairs. Pairs collaborated on a programming task using the think-aloud method, followed by individual retrospective interviews. Our findings revealed elevated productivity scores for mixed-race pairs, with no differences in code quality between same- and mixed-race pairs. Mixed-race pairs excelled in task distribution, shared decision-making, and role-exchange but encountered communication challenges, discomfort, and anxiety, shedding light on the complexity of diversity dynamics. Our study emphasizes race’s impact on remote pair programming and underscores the need for diverse tools and methods to address racial disparities for collaboration.
Article
The Multiuser Live Text Editor represents a dynamic platform fostering collaborative coding endeavors, enabling users to engage in real-time interaction while collectively crafting code. Boasting compatibility with prominent programming languages such as C++, Java, and Python, this innovative tool is founded upon the notion of adaptive functionality, a cornerstone of its shared editing capabilities. At its core lies pair programming, an agile methodology originating from Extreme Programming (XP), wherein two developers synergistically collaborate on a single computing environment. Tasked with jointly conceiving, implementing, and validating user stories, these pairs operate in tandem, leveraging their complementary skills to achieve shared objectives. Notably, this collaborative process thrives on the diversity of the paired developers' systems, with each individual allocated equal time at the keyboard.
Chapter
Full-text available
As the need for skilled computer programmers increases each year globally, so does the need for learning environments that serve the novice programmer. This literature review aims to contribute to the field of computer science education by highlighting successful practices reported in the literature and describing those practices through the lens of instructional design. As the demand for programmers increases, the success of novice programmers remains stagnant. By reviewing research-based instructional practices through the lens of instructional design, instructional designers, researchers, and CS, instructors can make purposeful design decisions in the future that help to meet the needs of the growing number of novice programmers. This chapter highlights the importance of instructional design theories and learning methods in meeting the diverse needs of computer science learners.
Article
The author has studied the effects of schedule compression or stretch-out on total project cost within a much broader effort to study and predict the dynamics of the entire development process. The resulting cost/schedule tradeoffs were examined. Much of this project involved developing a comprehensive system-dynamics model. He used the model to conduct three simulation experiments. (1) He investigated the effects of different levels of schedule compression and stretch-out on total project cost in man-days and compared the results to those reported in the literature. (2) He addressed the stealthy role undersizing plays in schedule compression. (3) He investigated how different levels of managerial commitment affect the project's final cost and completion time. The results of all three experiments are presented and discussed.< >
  • R G Miller
  • Anova
Miller, R.G. Beyond Anova, Basics of Applied Statistics. John Wiley and Sons, New York, 1986.
A dreamer finds the Expertise to Develop an Idea. The Philadelphia Inquirer
  • S Warner
Warner, S. A dreamer finds the Expertise to Develop an Idea. The Philadelphia Inquirer, Philadelphia, Penn., Dec. 1, 1996, D1.
  • R G Miller
  • Beyond Anova
Miller, R.G. Beyond Anova, Basics of Applied Statistics. John Wiley and Sons, New York, 1986.