Social Thinking: Designing the Next Generation of Social Software

TL;DR

In an era where software isn't just a tool but a medium for global interaction, traditional engineering is falling short. This paper argues that Social Thinking—the application of social science reflections—is essential for building modern software. By reporting on a novel "Social Software Engineering" course, the authors demonstrate how moving from "contracts" to "social evidence" transforms how developers approach problem-solving and design.

Contextual Positioning

This work acts as a pedagogical roadmap for a shift in the Software Engineering (SE) discipline. Rather than viewing SE as a purely technical optimization problem, the authors position it as a socio-technical endeavor. It is a transition from the rigid, client-focused world of the 1990s to the open, community-driven world of the Web 2.0 era.

The Core Friction: Contracts vs. Social Reality

The authors identify a fundamental mismatch between traditional SE pedagogy and the reality of modern software like Open Source or Social Networks.

• The Client Gap: In open-source or social projects, there is no single client to sign a contract.
• The Intent Gap: Requirements aren't just technical specs; they are reflections of human behavior.
• The Motivation: Why do people contribute to Wikipedia? Traditional SE doesn't care; Social SE makes it the central design pivot.

Methodology: From Interviews to Architecture

The proposed "Social Software Engineering" process replaces the classic requirements gathering phase with a rigorous Social Research phase.

1. The Architecture of the Course

The course follows a 14-week arc that prioritizes the "Why" before the "How":

1. Phase 1 (Weeks 1-5): Technology Background (Ruby on Rails).
2. Phase 2 (Weeks 6-8): Problem Formulation & Social Research.
3. Phase 3 (Weeks 9-10): Rational Design.
4. Phase 4 (Weeks 11-14): Agile Development & Evaluation.

2. Turning Data into Design

Students are required to conduct structured interviews (approx. 30 per group) to gather evidence. This evidence then serves as the "Rationale" for design decisions. For instance, if a survey reveals a lack of trust in online resources, the software design must prioritize a "Karma" or "Trust Network" feature.

Experiments & Real-World Results

The "social thinking" approach was tested through student-led open-source projects:

• Kiwish: A solidarity network for World poverty involving "wish lists" for charity.
• OSLP: A learning platform using trust networks to rank educational resources.

These projects weren't just coding exercises; they were attempts to solve societal "Social Problems." The authors found that students assimilated social research as a standard technical skill, proving that the methodology is teachable at the Bachelor's level.

Critical Insight & Future Outlook

The brilliance of this paper lies in its rejection of "Accidental Complexity." By using frameworks like Ruby on Rails, the authors force students to deal with the messy reality of modern development (outdated docs, undocumented plugins) while focusing their intellectual energy on the social logic.

Limitations

• Scalability: The course was taught to small groups (35 students over 3 years); it’s unclear if this high-touch coaching model can thrive in massive online or university settings.
• Framework Obsolescence: Relying on specific frameworks (like Rails or OpenSocial) risks the curriculum becoming outdated quickly.

Final Takeaway

Social software engineering isn't just about adding a "Like" button; it's about a Rational Design Process backed by evidence. As we move further into a world of decentralized social protocols and AI-mediated interactions, the "Social Thinking" framework will be more critical than ever.