A fascinating trend that I have noticed accelerating of late is the socialization of the development process. One of the more innovative corners of this trend is the introduction of social objects into the development world. A social object is a domain object in a business process which has been surfaced to interested parties independent of the normal process workflow and wrapped in social functionality to form a community and provide a system of record for the body of ad hoc processes that generally execute in parallel to the structured business process execution. An example of this is the work salesforce.com has done around sales processes with Chatter. Any opportunity, lead, contact, or other domain object has a full set of social/collaborative capabilities.
The typical set of features that make up a social object are the ability follow and receive updates to the social experience around the specific social object, express affiliation or interest to others, the ability to comment or otherwise carry on a conversation around the object, and a nexus of information in the form of a profile page. Often the ability to create relationships to other social objects orthogonally to the application data model is also supported. Likewise, you also often see collaborative content management around the social object. Examples of collaborative content management might include wiki like content creation, photos, documents, or other rich media.
In development organizations, we are seeing some very interesting social objects emerge.
The most common social object in development organizations is the requirement/story/feature. Most ALM tools are creating social experiences that allow an idea to form a community of stakeholders (customers, public, internal) and have that idea evolve into a fully fleshed out requirement or feature through dialog and social prioritization (idea networks and voting/ranking). Many organizations are extending this idea inside the feature implementation lifecycle with product managers, QA, developers, professional services, operations, and other constituents involved in the delivery of the feature to users. Less rework, better implementations, and shorter commercialization cycles are common benefits.
Beyond requirements, the code itself is becoming social objects. Historically, comments in code served as the primary repository of conversation between developers. Starting with the open source code repositories and extending to the commercial software tools vendors, code visualization systems layered on top of the source code repository are starting to provide conduits for conversation and communication. Wiki like rich annotation as well as threaded conversations and commenting are becoming a prevalent in tools like Github, Bitbucket, and Fisheye. Additionally, as code is getting created, the interpersonal feedback processes between developers is getting social as well. From change set comments to full blown collaborative code review tools, the conversations that used to take place in casual conversation and formal documents or meetings is moving into a free form, continuous conversation. The implications for knowledge capture and decision documentation are significant with the barriers to many objectives historically requiring onerous process becoming a by product of authentic and productivity enhancing collaboration.
While discussion forums and public bug tracking databases are the elder statesmen of the social object world in development, these tools are starting to provide more accessible tools for creating internal collaborative conversations between support, QA, developers, and product managers to streamline the effect resolution process. While few fundamental changes are taking place, the paradigm shift in design is making otherwise little used features more interesting with follow capabilities and links to actionable data like change sets for patches and links to test case repos.
Visionary social development practitioners are also extending the social object strategy to more interesting and less obvious domain objects. For examples, many are turning software builds into social objects so developers and QA professionals can collaborate on data and configuration dependancies required to test new versions of their software. These are replacing a high friction component of many development organizations with a natural collaborative alternative. Likewise, operations staff are exploring build based social objects an effective tool for satisfying ITIL and SAS70 requirements without elaborate handover documents and forms. Additionally, DevOps organizations can enhance the development and operations communication process based on the build based social collaboration.
It is still early and vendors are still have uneven support for the social object paradigm. However the derivative benefits are profound. It will be an interesting few years for tool vendors as they ride a renaissance in their market fueled by social innovations.
