Why Pair Programming Is Not Optional

Two developers, one screen, one problem. What sounds like waste is the best-evidenced method in software engineering - and yet most organizations ignore it. In this article we have compiled 25 years of research data: from Williams’ pioneering studies at the University of Utah through Cockburn’s field experiments to Arisholm’s controlled studies at Simula Research. The conclusion is unambiguous. Pair programming costs 15% more time - and saves multiples of that through fewer bugs, faster onboarding, and code that more than one person understands. Anyone who still lets developers work solo after reading this is doing so out of habit, not conviction.

The Myth of the Lone Genius

The romantic notion persists: a brilliant developer sits alone at the screen, thinks hard, and produces elegant code. Linus Torvalds wrote Git in a weekend. John Carmack built Doom engines single-handedly.

These stories are true. They are also irrelevant.

Enterprise software is not a weekend project. It consists of hundreds of integrations, regulatory requirements, team handoffs, and systems that have grown over years. In this context, working alone is not a sign of productivity. It is a risk factor.

The research over the last 25 years is remarkably clear. The numbers:

• 15% more total development time - not 100% ^[1]
• 15-60% fewer defects in code ^[1][4]
• 29% faster completion on complex tasks ^[2]
• 30-50% faster onboarding of new team members ^[1]
• 95% of pairing participants report higher satisfaction ^[2]
• 48% fewer lines of code for the same functionality ^[1]
• 30x higher costs when bugs are found in production ^[6]

This is not gut feeling. These are replicated study results from controlled experiments with hundreds of professional developers.

The KPI Collection: 25 Years of Research in Numbers

Defect Density and Code Quality

Study	n	KPI	Result
Williams & Kessler (2000) [1]	41	Tests passed first time	+15% vs. solo
Williams & Kessler (2000) [1]	41	Defect density	significantly lower
Nosek (1998) [2]	15	Functional correctness	higher for pairs
Nosek (1998) [2]	15	Code readability	higher for pairs
Arisholm et al. (2007) [4]	295	Error rate (complex tasks)	-60% vs. solo
Arisholm et al. (2007) [4]	295	Error rate (simple tasks)	marginal
Dyba et al. (2007) [5]	18 studies	Overall code quality	statistically significant improvement
Jensen (2003) [16]	120	Post-acceptance defects	-40%
Padberg & Mueller (2003) [17]	Simulation	Post-release defects	-20 to -40%

Time Expenditure and Productivity

Study	n	KPI	Result
Williams & Kessler (2000) [1]	41	Total development time	+15% (not +100%)
Nosek (1998) [2]	15	Elapsed time (complex task)	-29% faster
Arisholm et al. (2007) [4]	295	Effort (simple tasks)	+84%
Arisholm et al. (2007) [4]	295	Effort (complex tasks)	+18%
Cockburn & Williams (2001) [3]	Review	Break-even at defect reduction	from 3-5%
Lui & Chan (2006) [18]	40	Task throughput	+43% vs. solo

Satisfaction and Team Dynamics

Study	n	KPI	Result
Nosek (1998) [2]	15	Satisfaction with outcome	+95% for pairs
Williams et al. (2000) [1]	41	Would recommend to colleagues	96% would pair again
Begel & Nagappan (2008) [19]	106	Satisfaction with pairing (Microsoft)	65% satisfied
Begel & Nagappan (2008) [19]	106	See quality improvement (Microsoft)	74%

Code Efficiency

Study	KPI	Result
Williams & Kessler (2000) [1]	Lines of code (same functionality)	-48% fewer lines
Mueller (2004) [20]	Cyclomatic complexity	lower for pairs

The core finding across all studies: pair programming costs slightly more time. It produces less code that has fewer bugs, is easier to maintain, and is understood by more people.

”But I Am Faster Alone” - What Really Bothers Developers

Let us address the elephant in the room. Most developers who reject pair programming do not have numbers against it. They have a feeling. And that feeling is not irrational - it is simply incomplete.

”I cannot concentrate when someone watches me”

This is real. Research on Social Facilitation ^[10] shows, however, that the presence of an observer disrupts performance only for new, unpracticed tasks. For tasks you have mastered - the actual programming work - presence improves performance by 15-20%.

What you experience as “disruption” is your brain switching from System 1 (autopilot) to System 2 (analytical thinking) ^[9]. This feels more strenuous. But it produces better code. Every developer knows the feeling of writing a “brilliant” solution at 11 PM alone - that looks embarrassing the next morning. The partner prevents 11 PM decisions in real time.

”I need to think alone before I can code”

True. And that is exactly why pair programming does not mean two people sitting next to each other for 8 hours. The most effective practice according to a study by Chong and Hurlbutt (2007) ^[21]: 2-4 hour sessions with breaks for solo exploration.

The model: think solo, pair to build, think solo, pair to review. The studies measuring 15% additional effort with 60% fewer defects are based on this rhythm - not on 8-hour continuous pairing.

”My partner is too slow / too fast”

Skill mismatch is the most common problem in practice ^[19]. Begel and Nagappan (2008) found in their Microsoft study: 73% of developers who rejected pairing cited skill mismatch as the reason. Not pairing itself.

The solution is not no pairing. The solution is better matching. Their data also showed: with well-matched pairs, satisfaction was at 90% - and perceived productivity even exceeded solo work ^[19].

And here is the point nobody likes to hear: if you are always the “faster” one, you are also the knowledge monopolist. You are the bus factor of 1. Your team depends on you. Pairing with someone who is “slower” is not a brake - it is knowledge transfer. It is the cheapest insurance your team can buy.

”I lose my flow state”

Csikszentmihalyi’s flow theory ^[22] describes the state of complete absorption in a task. Solo programming can produce flow. But flow has a problem: it suppresses critical thinking. In flow state, warning signs are ignored, edge cases skipped, shortcuts taken that “feel right” ^[9].

What developers experience as “flow” is often System 1 running at full speed - fast, intuitive, and blind to its own errors. Pair programming replaces uncontrolled flow with productive focus: high concentration with simultaneous quality control.

The studies show: pairs report equal or higher job satisfaction compared to solo developers ^[2]. Flow is not the only recipe for good work. Shared focus is the more sustainable variant.

”Code reviews are sufficient”

Fagan (1976) ^[14] showed: formal code reviews find 60-70% of defects. That sounds good. Pair programming finds 85-95% ^[1]. But the decisive difference is not the rate - it is the timing.

A code review finds errors hours or days after they were written. The context is gone. The reviewer must reconstruct the thought process - and does so incorrectly in 60% of cases (Bacchelli & Bird, 2013) ^[23]. They approve code they do not fully understand because the social pressure is too great to keep a colleague waiting hours for an approve.

Pair programming does not have this problem. The navigator was present during the entire thought process. No context loss. No social pressure. And no queue in PR review that slows down the entire team.

”It is socially exhausting”

Yes. For introverted developers, continuous pairing is draining. This is not an argument against pairing - it is an argument for measured pairing. The research ^[21] recommends 50-70% pairing time, not 100%. Critical tasks (architecture, integration, security) in pairs. Routine work (configuration, simple bugs) solo.

The key finding: developers who “never” wanted to pair changed their minds after 2 weeks of consistent pairing - 96% would recommend it ^[1]. The initial rejection is almost always a comfort zone defense, not an evidence-based position.

The Cognitive Explanation: Why Two Brains Outperform One

Cognitive Load Theory (Sweller, 1988) ^[7]

Every person has a limited capacity for simultaneous information processing in working memory. Miller (1956) ^[8] quantified this capacity at 7 plus or minus 2 units. When programming, up to 12-15 parallel demands compete for this capacity: syntax, logic, system architecture, edge cases, naming conventions, testing requirements, API contracts, performance implications.

In pair programming, this load distributes across two working memories. The driver focuses on the tactical level: syntax, variable names, current function. The navigator keeps the strategic level in view: does the solution fit the overall architecture? Is an edge case missing? Is there a simpler variant?

Measurable: pairs consider 40% more edge cases than solo developers on the same task ^[17]. Not because they are smarter. But because their combined cognitive capacity is higher.

Verbalization Effect (Chi et al., 1989) ^[11]

One of the most powerful debugging tools is rubber duck debugging: explaining the problem out loud, even if only a rubber duck is listening. Chi et al. demonstrated the Self-Explanation Effect: students who explained their solution steps aloud achieved problem-solving test scores 2.5x higher than silent problem-solvers. The error rate dropped by 30% ^[11].

Pair programming institutionalizes this effect. Every decision must be explained to the partner. “I am using a HashMap instead of an ArrayList here because…” - the sentence forces justification. And justifications that are not convincing get challenged. Before the code is written, not weeks later in code review.

Dual Process Theory (Kahneman, 2011) ^[9]

Daniel Kahneman’s Dual Process Theory distinguishes two thinking modes: System 1 (fast, intuitive, error-prone) and System 2 (slow, analytical, precise). In solo programming, System 1 dominates - developers copy known patterns, skip checks because “that has always worked.”

The partner activates System 2. Not through control, but through mere presence. Social psychology calls this Social Facilitation ^[10]: the presence of a competent observer improves performance on well-practiced tasks by 15-20%.

Working Memory Complement (Flor & Hutchins, 1991) ^[24]

Two programmers do not simply share the work. They complement their working memories. What person A overlooks, person B notices - not because B is more attentive, but because attention scatters statistically.

The mathematical consequence: if a solo developer detects a specific class of errors with 90% probability, two independent developers detect the same error class with 99% probability (1 - 0.1 x 0.1). At a detection rate of 80%, the pair detection rate rises to 96%. This statistical effect alone explains a large portion of the observed defect reduction.

The Psychological Dimension: Safety, Knowledge, Belonging

Psychological Safety (Edmondson, 1999) ^[12]

Amy Edmondson coined the term Psychological Safety: the belief that one can admit mistakes, ask questions, and take risks in a team without being punished.

• Google Project Aristotle (2015) ^[13]: Psychological Safety was the #1 predictor of team performance - more important than structure, clarity, meaning, or dependability
• Edmondson (1999) ^[12]: teams with high Psychological Safety reported 70% more errors and could fix them faster as a result
• Rozovsky (2015) ^[13]: teams in the top quartile for Psychological Safety had 17% higher productivity and 40% lower attrition

Pair programming creates a natural framework for this. “I do not understand what this API returns” is a normal statement in a pairing session. In a solo setting, the same uncertainty often goes unspoken - and becomes a bug.

Knowledge Distribution and Bus Factor

The cost of knowledge loss in numbers:

• Bus factor of 1 (only one person knows the code): risk of complete project failure on personnel change
• Knowledge loss through attrition: with each departure, 42% of process-relevant knowledge is lost - of which 70% is tacit, meaning undocumented ^[15]
• Cost of re-onboarding: 6-12 months until a new developer is productive in an enterprise project, 3-6 months with pair onboarding ^[1]
• Attrition costs: 50-200% of annual salary per departure (SHRM, 2019)

Pair programming is the most reliable mechanism we know to distribute tacit knowledge from individual heads into the team.

Onboarding Acceleration

• 30-50% faster productivity with pair onboarding vs. self-study ^[1]
• 75% of onboarding pairs feel “ready for independent work” after 2 weeks vs. 25% with solo onboarding ^[21]
• Cognitive Apprenticeship (Collins, Brown & Newman, 1989) ^[25]: learning through observation and gradual takeover is 2-3x more effective than instruction-based learning for complex tasks

The Business Case: The Complete Calculation

Mistake 1: The 100% Assumption

Pairs do not take twice as long:

• Simple tasks: +84% effort ^[4] - pairing rarely pays off here
• Medium tasks: +15% effort ^[1]
• Complex tasks: +18% effort with simultaneously -60% defects ^[4]
• Elapsed time (complex task): -29% faster to completion ^[2]

Pairs discard bad approaches 4x faster because the navigator recognizes the thinking error earlier ^[18].

Mistake 2: Defect Costs Are Ignored

The cost escalation curve per Boehm and Basili (2001) ^[6]:

Phase	Remediation cost (relative)	Example (at EUR 500 base cost)
Coding	1x	EUR 500
Code review	2x	EUR 1,000
Integration/testing	5x	EUR 2,500
System test	10x	EUR 5,000
Production	30x	EUR 15,000
Post-release (customer affected)	100x	EUR 50,000

The National Institute of Standards and Technology (NIST) ^[26] estimated the annual cost of software defects in the US at USD 59.5 billion. Of that, USD 22.2 billion (37%) could have been avoided through earlier defect detection.

Mistake 3: Knowledge Costs Are Ignored

When a developer quits and no one knows their code:

• Reverse engineering: 2-6 months of effort
• Elevated error rate during transition: +200-300%
• Delayed feature delivery: 3-9 months until normal state
• Total attrition cost: 50-200% of annual salary (SHRM, 2019)

The Full Calculation (Model Project)

For an enterprise project with 10 developers, 12-month duration:

Item	Solo	Pairing	Delta
Development effort	Baseline	+15%	+EUR 105,000
Defect remediation (test)	Baseline	-40%	-EUR 120,000
Defect remediation (production)	Baseline	-50%	-EUR 225,000
Knowledge transfer/onboarding	Baseline	-40%	-EUR 80,000
Documentation effort	Baseline	-30%	-EUR 25,000
Net savings			-EUR 345,000

The numbers vary by project. The direction does not. In enterprise development - where a production bug in a payroll (UK: PAYE) system or an interface to SAP affects thousands of employees - solo development is the more expensive model.

Real-Time Review vs. Post-Hoc Review

KPI	Post-hoc code review	Pair Programming	Source
Defect detection	60-70%	85-95%	[14] [1]
Time to detection	Hours to days	Seconds	Structural
Context loss	High	Zero	[23]
Review misunderstandings	60% (reviewer misunderstands intent)	0%	[23]
PR wait time	4-24 hours (team blocker)	0	Structural
Knowledge transfer	Low (only code visible)	High (decision process visible)	[24]

Bacchelli and Bird (2013) ^[23] analyzed code reviews at Microsoft and found: in 60% of cases, the reviewer did not correctly understand the author’s intent. Reviews that were supposed to find bugs degenerated into style discussions. The main reason: missing context.

The Human Factor: Why Pairing Matters More in the AI Era, Not Less

There is an argument for pair programming that appears in no study from the 2000s - because the problem did not exist back then.

In 2026, developers spend a growing share of their workday in dialogue with AI assistants. Code is generated with Copilot, architecture questions posed to Claude, debugging performed with ChatGPT. The productivity gains are real. But a side effect is emerging that nobody planned for: professional isolation.

The numbers are alarming:

• Gallup State of the Global Workplace (2024): only 23% of employees worldwide feel engaged at work. For remote knowledge workers, the figure is 18%
• Microsoft Work Trend Index (2024): 68% of developers report that on some days they do not speak with anyone on their team about work
• Buffer State of Remote Work (2024): 23% of remote workers name loneliness as their biggest challenge - ahead of “distractions” and “motivation”
• Murthy (2023): the US Surgeon General declared workplace loneliness a Public Health Crisis with measurable effects on productivity, creativity, and error rates

A developer who spends 8 hours a day talking to an LLM and no one on their team makes decisions in a vacuum. The LLM does not push back from experience. It does not know the team dynamics. It does not know that the last developer who “quickly” changed the database structure caused three weeks of cleanup. It has no opinion based on scars.

Social Cognition vs. Tool Cognition

Neuroscience distinguishes two networks in the brain ^[27]: the Task-Positive Network (activated during problem-solving, tool use, focused work) and the Default Mode Network (activated during social cognition, perspective-taking, empathy). During solo programming with AI assistants, almost exclusively the Task-Positive Network is active. The Default Mode Network - responsible for “How would my colleague see this?” - stays silent.

Pair programming activates both networks simultaneously: problem-solving and social cognition. The result is decisions that are not only technically correct but also consider the team context.

Trust Is Built Through Shared Work, Not Slack Messages

Dutton and Heaphy (2003) ^[28] studied “High-Quality Connections” in the workplace: brief, intense interactions that generate trust, energy, and mutual appreciation. Their research shows:

• A single day of intensive collaboration generates more trust than weeks of asynchronous communication
• Teams with regular high-quality connections have 25% lower attrition and 30% higher engagement ^[28]
• Trust built through shared problem-solving is 3x more stable than trust built through social events ^[12]

Pair programming is the densest form of professional interaction that exists. Two people solve a problem together, share frustration and success, learn how the other thinks. This is not a soft-skill bonus. It is the glue that holds functioning teams together.

The Counter-Calculation: What Happens When Teams Stop Talking

• Silo formation: without regular professional exchange, knowledge islands form. Each developer builds their own mental model of the system - and those models diverge over time ^[15]
• Duplicate work: without visibility into others’ work, 15-25% of features are implemented redundantly (Herbsleb & Grinter, 1999) ^[29]
• Quality loss: developers who feel socially isolated show 33% more defects than engaged team members (Begel & Nagappan, 2008) ^[19]
• Burnout: professional isolation is one of the strongest predictors of burnout among knowledge workers (Maslach & Leiter, 2016) ^[30]

The irony: AI assistants make individual developers more productive. But they make teams more fragile - when pairing is absent as a counterweight. The solution is not less AI. The solution is intentional human interaction as a standard process. Pair programming is the simplest and most effective path to get there.

What This Means for Enterprise Development

In enterprise software development all the above effects compound:

Integration complexity. When an agent must connect to SAP, DATEV, and Microsoft Graph, cognitive load per task rises to 15+ parallel contexts. Exactly the situation where pair programming shows the greatest advantage: +18% effort with -60% defects ^[4].

Regulatory requirements. Compliance-relevant code demands correctness. The 99% detection rate (vs. 90% solo) for critical error classes is not a nice-to-have. It is a business requirement.

Four-eyes principle. In regulated industries, compliance mandates a four-eyes principle (MaRisk, ISO 27001). Pair programming fulfills this requirement natively - zero additional effort for compliance review.

Co-Build as a model. At Gosign we work in a Co-Build model: customer teams develop with us, not alongside us. This is pair programming at the organizational level - 100% knowledge transfer to the customer team, no vendor lock-in.

The Summary in Numbers

KPI	Solo	Pair Programming	Source
Development time	Baseline	+15%	[1]
Elapsed time (complex)	Baseline	-29%	[2]
Defect density	Baseline	-15 to -60%	[1] [4]
Lines of code (same function)	Baseline	-48%	[1]
Tests passed first time	Baseline	+15%	[1]
Onboarding duration	3-6 months	1.5-3 months	[1]
Satisfaction	Baseline	+95%	[2]
Would pair again	n/a	96%	[1]
Bus factor	1	At least 2	Structural
Post-release defects	Baseline	-20 to -40%	[17]
Defect detection (critical)	90%	99%	Statistical
Cost per defect (production)	30x coding	Avoided	[6]
PR review wait time	4-24h	0	Structural
Code review misunderstandings	60%	0%	[23]

Conclusion

The question is not whether an organization can afford pair programming. The question is whether it can afford to go without it.

15% more development time. 60% fewer defects. 40% faster onboarding. 48% less code. 99% detection rate for critical errors. EUR 345,000 net savings per year in the model project.

And to the developers who find pairing annoying: 96% of your colleagues changed their minds after two weeks of consistent pairing ^[1]. The evidence does not say pairing is comfortable. It says it works better. For the code, for the team, and for you.

Pair programming is not a preference. It is an engineering decision with measurable ROI.

Software Engineering at Gosign - Co-Build Instead of Black Box

Why AI Projects Fail - and What Decision Architecture Has to Do With It

AI Agents - Custom Solutions in the Co-Build Model

---

References

[1] Williams, L. & Kessler, R. (2000). “All I Really Need to Know About Pair Programming I Learned in Kindergarten.” Communications of the ACM, 43(5), 108-114. University of Utah.

[2] Nosek, J.T. (1998). “The Case for Collaborative Programming.” Communications of the ACM, 41(3), 105-108.

[3] Cockburn, A. & Williams, L. (2001). “The Costs and Benefits of Pair Programming.” Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000), 223-243.

[4] Arisholm, E., Gallis, H., Dyba, T. & Sjoberg, D.I.K. (2007). “Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise.” IEEE Transactions on Software Engineering, 33(2), 65-86.

[5] Dyba, T., Arisholm, E., Sjoberg, D.I.K., Hannay, J.E. & Shull, F. (2007). “Are Two Heads Better than One? On the Effectiveness of Pair Programming.” IEEE Software, 24(6), 12-15.

[6] Boehm, B. & Basili, V. (2001). “Software Defect Reduction Top 10 List.” IEEE Computer, 34(1), 135-137.

[7] Sweller, J. (1988). “Cognitive Load During Problem Solving: Effects on Learning.” Cognitive Science, 12(2), 257-285.

[8] Miller, G.A. (1956). “The Magical Number Seven, Plus or Minus Two.” Psychological Review, 63(2), 81-97.

[9] Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux. New York.

[10] Zajonc, R.B. (1965). “Social Facilitation.” Science, 149(3681), 269-274.

[11] Chi, M.T.H., Bassok, M., Lewis, M.W., Reimann, P. & Glaser, R. (1989). “Self-Explanations: How Students Study and Use Examples in Learning to Solve Problems.” Cognitive Science, 13(2), 145-182.

[12] Edmondson, A. (1999). “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly, 44(2), 350-383.

[13] Rozovsky, J. (2015). “The Five Keys to a Successful Google Team.” re:Work, Google.

[14] Fagan, M.E. (1976). “Design and Code Inspections to Reduce Errors in Program Development.” IBM Systems Journal, 15(3), 182-211.

[15] DeLong, D.W. (2004). Lost Knowledge: Confronting the Threat of an Aging Workforce. Oxford University Press.

[16] Jensen, R.W. (2003). “A Pair Programming Experience.” CrossTalk: The Journal of Defense Software Engineering, 16(3), 22-24.

[17] Padberg, F. & Mueller, M. (2003). “Analyzing the Cost and Benefit of Pair Programming.” Proceedings of the 9th International Software Metrics Symposium (METRICS 2003), IEEE, 166-177.

[18] Lui, K.M. & Chan, K.C.C. (2006). “Pair Programming Productivity: Novice-Novice vs. Expert-Expert.” International Journal of Human-Computer Studies, 64(9), 915-925.

[19] Begel, A. & Nagappan, N. (2008). “Pair Programming: What’s in it for Me?” Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), 120-128.

[20] Mueller, M. (2004). “Are Reviews an Alternative to Pair Programming?” Empirical Software Engineering, 9(4), 335-351.

[21] Chong, J. & Hurlbutt, T. (2007). “The Social Dynamics of Pair Programming.” Proceedings of the 29th International Conference on Software Engineering (ICSE), 354-363.

[22] Csikszentmihalyi, M. (1990). Flow: The Psychology of Optimal Experience. Harper & Row. New York.

[23] Bacchelli, A. & Bird, C. (2013). “Expectations, Outcomes, and Challenges of Modern Code Review.” Proceedings of the 35th International Conference on Software Engineering (ICSE), 712-721.

[24] Flor, N.V. & Hutchins, E.L. (1991). “Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance.” Proceedings of the Fourth Annual Workshop on Empirical Studies of Programmers, 36-64. Ablex Publishing.

[25] Collins, A., Brown, J.S. & Newman, S.E. (1989). “Cognitive Apprenticeship: Teaching the Crafts of Reading, Writing, and Mathematics.” In L.B. Resnick (Ed.), Knowing, Learning, and Instruction: Essays in Honor of Robert Glaser, 453-494. Lawrence Erlbaum Associates.

[26] National Institute of Standards and Technology (2002). “The Economic Impacts of Inadequate Infrastructure for Software Testing.” NIST Planning Report 02-3.

[27] Fox, M.D. et al. (2005). “The Human Brain Is Intrinsically Organized into Dynamic, Anticorrelated Functional Networks.” Proceedings of the National Academy of Sciences, 102(27), 9673-9678.

[28] Dutton, J.E. & Heaphy, E.D. (2003). “The Power of High-Quality Connections.” In K.S. Cameron, J.E. Dutton & R.E. Quinn (Eds.), Positive Organizational Scholarship, 263-278. Berrett-Koehler Publishers.

[29] Herbsleb, J.D. & Grinter, R.E. (1999). “Architectures, Coordination, and Distance: Conway’s Law and Beyond.” IEEE Software, 16(5), 63-70.

[30] Maslach, C. & Leiter, M.P. (2016). “Understanding the Burnout Experience: Recent Research and Its Implications for Psychiatry.” World Psychiatry, 15(2), 103-111.