<<

2 ◾ Engineering

Table 1.1 Classic Project Problems

People-Related Process-Related Product-Related Technology- Mistakes Mistakes Mistakes Related Mistakes

Undermined Overly optimistic Requirement Silver-bullet motivation schedules gold-plating, i.e., syndrome, i.e., too many latching onto product features new technology or method that is unproven for project

Weak personnel Insufficient risk Feature creep Overestimated management savings from tools or methods

Uncontrolled Contractor Developer Switching tools problem failure gold-plating, i.e., in middle of employees use of project technology for the sake of using that technology

Heroics Insufficient Push me–pull me Lack of planning negotiation, i.e., automated constantly source code changing control schedule

Adding people to Abandonment of Research- late project planning under oriented pressure development, i.e., stretching limits of technology

Noisy crowded Wasted time offices before project starts, i.e., approval and budgeting processes

Friction between Shortchanged developers and upstream customers activities, e.g., , etc. Why Social Networking? ◾ 3

Table 1.1 (continued) Classic Software Development Project Problems

Unrealistic Inadequate expectations design

Lack of effective Short-changed project quality assurance sponsorship

Lack of Insufficient stakeholder management buy-in controls

Lack of user Premature or too input frequent convergence, i.e., product released too early

Politics over Omitting substance necessary tasks from estimates

Wishful thinking Planning to catch up later

Code-like-hell programming

Online-Time Warner had just started an important new project when a new presi- dent was installed. The new president did what all new presidents do. He engaged in a little housecleaning. Projects—and some people—were swept away. When the dust settled, the project manager faced a whole new set of priorities and a bunch of new team members. As you can see, today’s dynamically changing, and very volatile, business landscape can play havoc with efforts and going global adds an entirely new dimension to the mix. What we need, then, is a whole new paradigm of software development that places the human aspect at the center of software engineering.

The Social networking is a hot topic. More than 30 billion pieces of content are shared on each month and Nielsen researchers say that consumers spend more than 5½ hours on social networking sites per day. So I am sure it doesn’t come as a surprise that social networking has made its way into the workplace. 4 ◾ Social Software Engineering

Table 1.2 Success and Failure Factors

Factors related to project

Size and value Having clear boundary Urgency Uniqueness of project activities Density of project network (in dependencies between activities) Project life cycle End-user commitment Adequate funds and resources Realistic schedule Clear goals and objectives

Factors related to project manager and leadership

Ability to delegate authority Ability to trade off Ability to coordinate Perception of role and responsibilities Effective leadership Effective conflict resolution Relevant past experience Management of changes Contract management Situational management Competence Commitment Trust Other communication

Factors related to project team members

Technical background Communication Troubleshooting Effective monitoring and feedback Commitment Why Social Networking? ◾ 5

Table 1.2 (continued) Success and Failure Factors

Factors related to organization

Steering committee Clear organization and job descriptions Top management support Project organization structure Functional manager’s support Project champion

Factors related to environment

Competitors Political environment Economic environment Social environment Technological environment Nature Client Subcontractors

As early as 2008, AT&T released the results of a research study it commissioned in Europe. The study conducted by Dynamic Markets found that the use of social networking tools led to an increase in efficiency. Of the 2,500 people surveyed in five countries, 65% said that use of these tools made them or their colleagues more efficient and 46% insisted that networking tools sparked ideas and creativity (AT&T, 2008). Deep Nishar is vice president of products and user experience at LinkedIn and manages a group of data researchers who look at everything from data center behav- ior to trends in search and mobile communications. His eclectic staff have experi- ence in such fields as brain surgery, , meteorology, and poetry. According to Nishar, machine-based systems like Google can’t keep up with orga- nizing the data they capture. Interesting and important problems will be solved by looking at social networks (Hardy, 2010). In 1976, science fiction author Richard Dawkins coined the term meme to describe an idea that moves from person to person and onward. With social net- working tools, staff can check to see what ideas people discuss within an organiza- tion. Some refer to the activity as a “meme broadcast tool.” Where marketers have Twitter to communicate with people outside the company, business people can use services such as Yammer (yammer.com) to share information within a company, 6 ◾ Social Software Engineering discuss relevant issues, and more. Table 1.3 lists some of the more popular social networking tools in use today. Leading-edge organizations have already figured out how to make social network- ing profitable. SolarWinds, a network management company, built a 25,000-member user of network administrators who help each other with various prob- lems. This allows the company to support a customer base of over 88,000 companies with only two customer support people. Cisco created employee councils and shifted decision making down to these levels through the support of collaborative technolo- gies. Indeed, Cisco’s CEO, John Chambers, insists that most of the progress made dur- ing the past 2 years has resulted from the use of collaborative and social technologies. When IBM transformed an Intranet into a social network, it provided each of IBM’s 365,000 employees a voice and identity that not only helped increase Table 1.3 Social Networking Tools

Social networking Facebook, , LinkedIn, , , Bebo, KickApps, OpenACircle, Vyew, MOLI, Fast Pitch!, Plaxo, Yammer, Eurekastreams.org, researchgate. net/

Publishing TypePad, Blogger, Wikipedia, Joomla

Photo sharing Radar.net, SmugMug, Zooomr, Flickr, Picasa, Photobucket, Twitxr

Audio iTunes, Rhapsody, Podbean, .com

Video Youtube, Metacafe, Hulu, Viddler, Google Video, Brightcove

Microblogging Twitxr, Twitter, Plurk

Livecasting SHOUTcast, BlogTalkRadio, TalkShoe, Justin.tv, Live365

Virtual worlds There, SecondLife, ViOS, ActiveWorlds

Productivity ReadNotify, Zoho, Zoomerang, Google Docs

Aggregators Digg, Yelp, iGoogle, Reddit, FriendFeed, TiddlyWiki

Rich site summary (RSS) RSS 2.0, , PingShot

Search Technorati, Redlasso, EveryZing, MetaTube, IceRocket, Google Search

Mobile Jumbuck, CallWave, airG, Jott, Brightkite

Interpersonal WebEx, iChat, Meebo, Acrobat Connect, Goto Meeeting, Skype Why Social Networking? ◾ 7 effectiveness and productivity but also helped workers transcend national cultures (How social networking, etc., 2009). IBM uses a variety of social networking tools. Long before Facebook graduated from college, IBM created its own internal social networking site called BluePages. It lists basic information about individual employees, their views, who reports to them, to whom they report, what organiza- tion they are in and what they are parts of. Employees can self-edit their listings and even add pictures. Clicking on an entry allows someone to send an instant message. Perhaps the most powerful feature is social tagging, also called social bookmark- ing. Clicking on an employee not only brings up identifying data, it also brings up his or her tags, i.e., feeds, RSS feeds, communities joined, social networks joined, recent forum entries, and participation. Ethan McCarty, former editor in chief of IBM’s intranet, describes it, “If you think of the phases of the intranet and even communication, first it’s about access to information, then it’s about transacting with it—like e-business—and now it’s more about people.” The people we refer to as the millennials come into the workplace with cell phones glued to their ears and fingers firmly glued to keyboards as they tweet and Facebook to friends and strangers alike. They think that talking on the phone is passé. Some don’t even have landlines. They communicate via social networks, instant messages, Twitter, and smartphones. However, their older brothers and sisters of Gen-Y are working to convince technology management of the values of these new technologies, according to a Forrester Research survey of 2,000 IT professionals. This isn’t all that surprising as a 2010 Pew report found that Internet users from all age groups increased their usage between 2008 and 2010. While 83% of those between 18 and 33 use social networking, those 45 and older more than doubled their Internet participation (Major trends, 2010).

The Software Engineering Social Network The development of software systems has long been considered a social activity. Software is developed using a team model and the work is divided among the vari- ous team members. Several studies suggest that developers of large projects spend 70 to 85% of their time working with others. Thus, it is important that a team col- laborate effectively to achieve a common goal. One of the earliest to research the psychology and sociology behind software engineering was Gerald M. Weinberg in 1971. His seminal book on the psychology of programming was radical for its time. Aside from coining the “egoless program- ming” phrase, Weinberg’s book on micro organizational behavior delves deeply into the concept of programming as a social construct and offers advice on dealing with team dysfunction. Much of the literature on the psychology of software development concludes that most of the social problems inherent in development teams can be solved by a 8 ◾ Social Software Engineering critical analysis of the dynamics among the people involved. This sort of introspec- tive analysis can be helpful to explain (1) why certain people are excluded from group decision making, (2) why someone always resists the decisions of project leadership, (3) why certain kinds of people should never be grouped together to avoid group fragmentation, (4) why groups often divide themselves into subgroups, and (5) the difference between the “real” chain of command and the formal one (Ahmadi, Jazayeri, Lelli, and Nesic, 2008). Fischer (2005) discusses the individual and social perspectives that affect design. Individuals often worry about whether they are interested enough to be effective during the span of a project. They also worry about whether they have something relevant to add to a group and can express it clearly so that others might under- stand them. On the other hand, the group is interested in hearing from a wide variety of stakeholders. Thus, the group is concerned with encouraging individuals to contribute, preventing voices from being lost because too much information is available, avoiding illegitimate voices, preventing getting stuck in group think, and eliminating sources of exclusion. A multitude of studies have discussed the vast amounts of time spent on commu- nication and collaboration with others. Because software development is an inher- ently collaborative and distributed process involving teams of developers working intra- and inter-organizationally and globally, it is logical that these teams require toolsets designed specifically for the collaborative, distributed nature of their work.

Collaborative Applications The computer-supported cooperative work (CSCW) community has been studying computer-assisted collaboration for some time. CSCW researchers have developed a number of frameworks that seek to categorize the requirements of the collab- orative toolset. Whitehead (2007) categorizes engineering tools into four groups: (1) model-based collaboration tools, (2) process support tools, (3) collaboration awareness tools, and (4) collaboration infrastructure tools. Sarma’s (2005) framework classifies tools based on the required effort to collaborate effectively. The framework consists of five layers and three strands, as shown in Figure 1.1. The layers are tools and the strands are critical needs that permeate all aspects of collaboration. As is often the case, many of the toolsets discussed in the literature are experi- mental and not offered for use by those in the field. In 2003, Booch and Brown sur- veyed both experimental and commercial collaborative development environments (CDEs). Their definition of a CDE is a virtual space wherein all the stakeholders of a project, even if distributed by time or distance, may negotiate, brainstorm, discuss, share knowledge, and generally labor together to carry out some task, most often to create an executable deliverable and its supporting artifacts. As encompass- ing as this definition is, it does not necessarily distinguish private and public (open Why Social Networking? ◾ 9

Continuous coordination Seamless Collaborative architecture Seamless development environments

Passive awareness of development activities Passive Advanced conflict Collocation benefits to and developers, manage detection distributed development

Instant messaging, Fine-grained Organizational memory, Proactive monitoring versioning, conflict knowledge acquisition and changes to artifacts resolution dissemination, social navigation

Parallel development, Defined Communication archival Prescribed and defined and roles and access along with artifacts coordination support rights

Access to a common Asynchronous set of artifacts, Task allocation and Functional communication isolated workplaces assignment and version control Communication Artifact Task Management Management

Figure 1.1 Collaboration framework. source) projects and does not necessarily stress software development. Still, their analysis of the requirements of a CDE is worthwhile to discuss. They base their requirements list on Fournier (2001). Table 1.4 lists the combined Fournier and Booch and Brown requirements for this sort of environment. Web 2 technologies have finally given a voice to the collaborative needs of software developers and can lend a hand toward building the type of CDE envi- sioned in Table 1.4. Web 2 engages users to build collective intelligence. One of the most common examples of this is the wiki (wiki is a variant of the Hawaiian wicki meaning fast). are so ubiquitous that the learning curve is minimal. Many organizations use this tool, specifically IT departments within organiza- tions, and several articles were written about the use of wikis to promote software reuse within IT departments. However, wikis have their own attendant prob- lems. Insufficient usage and decaying structures must be addressed if wikis are to be successful. The advent of social networking services such as LinkedIn, Facebook, and MySpace demonstrate the power of social networks and provide insights into what could be created specifically for software engineering. Of course, the current state- of-the-art social networks present some limitations, as Ahmadi et al. (2008) thor- oughly describe. Chief among the described problems is the lack of interoperability 10 ◾ Social Software Engineering

Table 1.4 Recommended Feature Set of Collaborative Development Environment

Coordination

Centralized information management Configuration control of shared artifacts Online event notification Calendaring and scheduling Project resource profiling Project dashboards and metrics (Booch and Brown) Searching and indexing of resources and artifacts Electronic document routing and workflow Virtual agents and scripting of tasks (Booch and Brown)

Collaboration

Threaded discussion forums (Booch and Brown) Virtual meeting rooms Online voting and polling Shared whiteboards Co-browsing of documents Multiple levels of information visibility (Booch and Brown)

Community Building

Personalization capabilities (Booch and Brown) Established protocols and rituals Well-defined scope and leadership Self-publication of content (Booch and Brown) Self-administration of projects (Booch and Brown) among social networks. The authors suggest leveraging semantic web technologies, one of which is the ontology, as a solution to this problem. An ontology is a formal representation of specific domain concepts and the relationships of those concepts. Several ontologies (e.g., www.foaf-project.org, www.sioc-project.org, http://www. semanticdesktop.org/ontologies/pimo/) have become universally recognized and it is expected that at some point interoperabilities of social networks using ontologies will become standard practice. Why Social Networking? ◾ 11

Indeed, some researchers have advocated for the use of ontologies to improve the discipline of software development. Mavetera and Kroeze (2010) discuss the different ontology types that can be used. A domain ontology describes the knowledge to be captured during the requirements analysis phase of software development. Method ontologies capture the knowledge and reasoning needed to perform a task. Status ontologies, either dynamic or static, capture the status characteristics of a system. Intentional ontologies model the softer aspects of living things such as beliefs, desires, and intentions. Process ontologies capture (1) enterprise knowledge (processes, orga- nizational structure, IT structure, products, customers); (2) domain knowledge (terms, concepts, relationships); and (3) information knowledge (document types and structures). Finally, social ontologies describes the organizational structures and interdependencies among the social actors (analyst, tester, developer, etc.).

We’ve Reached the End of Chapter 1 Sure, we can all use Microsoft Sharepoint, Oracle Beehive, or glue together any num- ber of social networking tools such as wikis and to effect a viable software solu- tion. We’re going to discuss many of these in this book, and even show you how to use them. You’ll find that several good social networking tools exist. When I first approached writing this book, I thought that the subject was a problem in search of a software solution. However, the more research I did, and the more people I spoke with, the more I became convinced that the issue is really a problem in search of a process. The goal of the rest of this book, therefore, is to fuse software engineering methodology and toolsets to the underpinnings of social networking—knowledge sharing and transfer. Along the way, we will delve into psychosocial constructs such as action learning, action research, and action science. This trifecta, popularized in the annals of psychology and used to improve productivity and spur creativity among management types, fits well within the rubric of “social engineering.”

References Ahmadi, N., Jazayeri, M., Lelli, F., and Nesic, S. (2008). A survey of social software engi- neering. 23rd IEEE/ACM International Conference on Automated Software Engineering Workshops. pp. 1–12. AT&T. (2008). Social networking in the workplace increases efficiency. http://www.att.com/ gen/pressoom?pid=4800&cdvn=news&newsarticleid=26293 Booch, G. and Brown, A.W. (2003). Collaborative development environments. Advances in Computers, 59: 2–29. Ewusi-Mensah, K. (2003). Software Development Failures. Cambridge, MA: MIT Press. Fischer, G. (2005). Social creativity: making all voices heard. Proceedings of HCI International Conference, Las Vegas, July, CD. http://l3d.cs.colorado.edu/~gerhard/papers/social- creativity-hcii-2005.pdf 12 ◾ Social Software Engineering

Fournier, R. (2001). Teamwork is the key to remote development. Infoworld. http://www. itworld.com/IW010305tcdistdev Hardy, Q. (2010). LinkedIn plots career success paths. http://www.forbes.com/forbes/2010/ 0830/e-gang-linkedin-social-networking-deep-nishar-be-the-boss.html How social networking increases collaboration at IBM. (2009). Strategic Communication Management, 14: 32–35. Retrieved from ABI/Inform Complete. Hyvari, I. (2006). Success of projects in different organizational conditions. Project Management Journal, 37(4): 31–42. Major trends in online activities (2010). Pew Research. http://pewinternet.org/Reports/2010/ Generations-2010/Trends/Social-network-sites.aspx Mavetera, N. and Kroeze, J.H. (2010). An ontology-driven software development frame- work. Proceedings of 14th International Business Information Management Association Conference, Istanbul, June, pp. 1713–1724. McConnell, S. (1996). Rapid Development: Taming Wild Software Schedules. Redmond, WA: Microsoft Press. Sarma, A. (2005). A survey of collaborative tools in software development. Institute for Software Research, University of California, Irvine. http://citeseerx.ist.psu.edu/viewdoc/dow nload?doi=10.1.1.126.671&rep=rep1&type=pdf / Whitehead, J. (2007). Collaboration in software engineering: a roadmap. In Future of Software Engineering, New York: IEEE Computer Society, pp. 214–225.