Easterbrook on Socio-Technical Congruence

Des­pite tech­nical dif­fi­culties (presenter’s worst night­mare — LCD pro­jector bulb burnout), Steve East­er­brook demon­strated the use­ful­ness of com­par­ing soft­ware struc­tures to social net­works of developers to meas­ure oper­a­tional effect­ive­ness. His well argued and logical present­a­tion ‘Increas­ing Shared Under­stand­ing in Soft­ware Teams through Informal Know­ledge Trans­fer Net­works’ exten­ded Conway’s Law to social net­work ana­lysis. This tech­nique of meas­ur­ing socio-technical con­gru­ence is espe­cially valu­able in lar­ger scale devel­op­ment pro­jects, where it is prob­ably less obvi­ous about whether a devel­op­ment pro­cess is func­tion­ing effect­iv­elly. By min­ing the data rich envir­on­ment of com­mu­nic­a­tion and revi­sion logs, it is pos­sible to gen­er­ate a social net­work map of developer inter­ac­tion that can be con­nec­ted to a soft­ware devel­op­ment schem­atic to determ­ine Socio-Technical con­gru­ence.
Conway’s Law pos­its that “the struc­ture of a soft­ware sys­tem will reflect the struc­ture of the organ­iz­a­tion that builds it”. Today’s best prac­tices for object ori­ented devel­op­ment emphas­izes inform­a­tion hid­ing and effect­ive mod­ules that demon­strate min­im­ized coup­ling (inform­a­tion flow between mod­ules) and max­imal cohe­sion (the amount of com­mu­nic­a­tion within a mod­ule).
Although soft­ware engin­eers typ­ic­ally feel that this mod­u­lar­ity is import­ant because it reflects a logical view of how the soft­ware works, East­er­brook sug­gest that it is the social struc­ture of the team itself that forces mod­u­lar­ity. Because soft­ware con­tinu­ally evolves as fea­tures are added, cor­rect­ives applied and pre­vent­at­ive main­ten­ance under­taken, there are many pres­sures on the sys­tem and the largest cost and effort is hand­ling this evol­u­tion. With mod­u­lar­ity, struc­ture can rep­res­ent an assign­ment of respons­ib­il­ity and the most effect­ive way to meas­ure this is by determ­in­ing the link­age between the social nature of the devel­op­ment team and the struc­ture of the soft­ware sys­tem. This con­gru­ence can be meas­ured by two means: Arc Mirroring…dependancy at the soft­ware level reflect­ing rela­tion­ship at the social level…good sys­tem Sim­il­arly, Node Ties can demon­strate that people work­ing on same mod­ule are actu­ally talk­ing to one another as they should. If node ties are weak or dis­tant, then com­mu­nic­a­tion inef­fi­cien­cies can be iden­ti­fied and rectified.This ana­lysis can present a very clear pic­ture of how well the team is work­ing. If mod­ules are inter­de­pend­ant and people are talk­ing to one another, then devel­op­ment is efficient.

Effect­ive devel­op­ment is enhanced by dis­trib­uted cog­ni­tion and con­ser­va­tion of know­ledge. Nodes within the social graph should min­im­ize the amount of know­ledge trans­fer out­side of the imme­di­ate sphere of involve­ment to oper­ate most effectively.

To explore the effect­ive­ness of meas­ur­ing con­gru­ence, East­er­brook stud­ied the email logs of open source devel­op­ment. Using SNA tech­niques it was pos­sible to sys­tem­at­ic­ally determ­ine who spe­cific bugs should be referred to and who is the expert on a par­tic­u­lar mod­ule.
One of the excit­ing pos­sib­il­it­ies that East­er­brook raises for this tech­nique of socio-technical con­gru­ence is being able to extend it from the realm of the devel­op­ment team to being able to meas­ure con­gru­ence with the struc­ture of the cus­tomer organ­iz­a­tion itself to meas­ure soft­ware sys­tem effect­ive­ness.