Pair programming dilemma

Pair Programming happens to be one of the first casualties when shops hastily jump into agile bandwagon. (TDD/Test Driven Development is another). Maybe because it’s counterintuitive to many. The whole effectiveness of pair programming gets questioned (How can two working together not be wasting time?). Even Dilbert had his say.

Now with agile way of development gaining more ground, in all flavours – offshored, distributed, CMMised, PMIed, whatever – resistance to any practice can only weaken the whole concept of agile and squeezing the last drop out of it. (Though pair programming is not strictly tied to agile method and one can happily do it in non-agile settings, it gained more mileage piggybacking agile)

One way to counter counterintuitiveness is with empirical studies. Or with studies which explains why it works.

Stuart Ray has come up with such a brilliant article on pair programming which dives into cognitive science to explain how pair programming works. The article delves beautifully in the workings of brain and human behavior, and perhaps corroborates the fact that brain is more a social organ and cannot but feel better with increased chance of social interaction. He goes on to advance four mechanisms of pairing.

One is “Pair programming chat“. It seems talking about programming problems, even to oneself, helps getting unstuck. Stuart Ray goes on to give a wonderful cognitive rationale behind it with language module doing the trick with integrating knowledge held in other modules.

Carruthers suggested that we must rely on the language module posing the right question and that the other modules don’t usually present in­formation spontaneously. However, when we hear the right question, our brains make the nec­essary information available, and the language module can then perform rudimentary inference and draw the obvious conclusions. Carruthers suggested that the key is posing a question that’s “both relevant and fruitful.” The right question draws forth the crucial knowledge, and in a mo­ment of epiphany, the answer becomes obvious.

Next being “Pair programmers notice more details“. In this Stuart Ray talks how more details gets noticed under pair programming. So, two people programming together won’t have the same prior knowledge or categorization: one will presumably spot some things faster and the other different things. That is till pair fatigue sets in.

Then comes “Fighting poor practices“. Pair programming can nudge programmers to follow best practices or rather, to avoid poor practices. In his words, Pair programmers might be less susceptible to poor practices because they can promise to write code in a particular way and ensure that each other’s promises are kept.

And finally, “Sharing and judging expertise”. Programming is one area where you never know how skilled one is unless you get to work together with her. Stuart Ray argues rightly that the individual skill levels become transparent in a team which does peer programming. This argument might also help in managing or rewarding performance of people at individual level.

I tried to find some empirical studies on effectiveness of pair programming. In one study in Norway, 295 programmers were used to do a controlled experiment on pair programming. The results of this experiment do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. On the other hand, there is 84% increase in effort to perform the tasks correctly. However, on the more complex system, the pair programmers had a 48 percent increase in the proportion of correct solutions but no significant differences in the time taken to solve the tasks correctly. I believe the experiment missed out on a significant factor of pair programming effectiveness increasing with gelled teams and shared context, which is expected in real projects.

In one study to analyze cost and benefit for pair programming, Alistair Cockburn and Laurie Williams, found that for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels. To justify economics, the authors stresses the point that pair/collaborative programming reduces defects by a huge margin even if there is small increase in development effort, which in the end compares favorably cost-wise towards pair programming.

It will only help to consider such studies (or better trying it out) before ditching pair programming just because it happened to be counterintuitive to conventional wisdom. It will be a shame if in a rush to get agile branded shops cherry pick agile practices instead on building a foundation of right culture. It might help in sales gimmicks but not in greater good of agile.

Advertisements

Money, it’s a gas

It’s so true that it’s turning out into a cliché. Dan Pink’s ‘Drive‘ is out with the tagline ‘The surprising truth about what motivates us’. (Surprising to whom?). The Economist’s resident bard on business, Schumpeter, chimed in too, though surprisingly in right direction.

One can hardly help the feeling that we are directed towards a false dichotomy. It doesn’t have to be such. Intrinsic and extrinsic motivation are not mutually exclusive, and perhaps the need is to seek a balance or a holistic treatment taking the context in consideration. This is the very least to be expected from an author of a book on right brain thinking. The importance of context seems to be missing.

Schumpeter argues that for most of jobs being outsourced and automated, primary motivation need to be of intrinsic variety. (As if the people where the job is being outsourced to are too dumb or too cheap to need any intrinsic motivation). But people don’t always rely on their employer to unleash their creativity. There are millions who paint, write, make movies, form great organizations, champion causes, once their paying-the-bills-day-job is over. I saw a group of very passionate people holding onto their mundane jobs create and take to great heights a fine cinema club. Little wonder Hugh MacLeod had to suggest ‘Keep your day job‘. The losers here, hardly unsurprising, are the organizations.

In any case, it is next to impossible for anyone to imagine in separate context money and organization (at least in capitalism). Maybe that’s why not-for-profit and open source has involvement without monetary expectations, because the context itself is non-monetary, with organization not dying for the last dollar. Schumpeter also mentions “Paying people to give blood actually reduces the number who are willing to do so“. Because by linking it to money, market norms encroach on social norms; and expectations were different in both cases. Dan Ariely captures this well in his Predictably Irrational.

McKinsey Quarterly carried on with the suggestion that current recession gives the organization a good chance to move from financial to non-financial (intrinsic) opportunities. Money is scarce, employee morale seeing a new nadir everyday, yet the need for retaining and attracting talent is as crucial as ever. So, no better time than now to make the change.

McKinsey then asks: Why haven’t many organizations made more use of cost-effective nonfinancial motivators at a time when cash is hard to find?
It seems:

One reason may be that many executives hesitate to challenge the traditional managerial wisdom: money is what really counts. While executives themselves may be equally influenced by other things, they still think that bonuses are the dominant incentive for most people. “Managers see motivation in terms of the size of the compensation,” explained an HR director from the financial-services industry.

Another reason is probably that nonfinancial ways to motivate people do, on the whole, require more time and commitment from senior managers. One HR director we interviewed spoke of their tendency to “hide” in their offices-primarily reflecting uncertainty about the current situation and outlook. This lack of interaction between managers and their people creates a highly damaging void that saps employee engagement.

But there’s another dimension. And that’s money is not just about only money. It’s a lot more things.

In September 2003, Richard Grasso, who was then the head of the New York Stock Exchange, became the first CEO in American history to get fired for making too much money.

To explain, James Surowiecki in his brilliant ‘The Wisdom of Crowds‘ writes:

‘ The explanation for people’s behavior might have something to do with an experiment called the “ultimatum game,” which is perhaps the most well-known experiment in behavioral economics. The rules of the game are simple. The experimenter pairs two people with each other. (They can communicate with each other, but other they are anonymous to each other.) They’re given $10 to divide between them, according to this rule: One person (the proposer decides), on his own, what the split should be (fifty-fifty, seventy-thirty, or whatever). He then makes a take it or leave it offer to the other person (the responder). The responder can either accept the offer, in which case both players pocket their respective shares of the cash, or reject it, in which case both players walk away empty-handed.”

It seems it’s rational for proposer to make a lowball offer and the responder, left with no choice, to accept it. Whatever it is, responder is left with no money if he doesn’t accept it, which is worse than accepting a ridiculously lowball offer. In practice, though, this rarely happens. Responder, in most cases, rejects it.

This experiment is repeated across countries; with million dollar; with capuchin monkeys. The results are the same.

Because, money is an indicator of fairness, and humans and capuchin seem to care whether rewards are fair. It means people think it is very important that they (and everyone else) get what is deserved. People not only compare rewards within organization but also within society. We are all too familiar with banker bonuses and Wall Street packages. Also, we are not very unfamiliar to see in some cases the very executives championing intrinsic rewards eyeing fatter pay packages. Money being one of the few tangible things as far as rewards go, people are very likely to root for more money in such cases. If not anything else, it gives them the sense of being fairly treated.

Dilbert has a telling strip where Dilbert, Alice and Wally present a wrapped gift box to PHB pooling their bonus money, which on unwrapping appears to be empty. Dilbert and all say “Better luck next time”.

Agile and happiness

Flow is one word which finds itself both in Lean principles and also in psychology. (In lean principles, flow refers to the flow of value whereas in psychology, it refers to highly attentive state of mind). At first glance, it’s hard to see any connection (but, it seems, there is). Whatever, I couldn’t help wondering – does working lean make people any happier?

James.P.Womack and Daniel.T.Jones in their classic ‘Lean Thinking‘ bridges between two flows (Chapter: Flow):

Classic batch-and-queue work conditions are hardly conducive to psychological flow. The worker can see only a small part of the task, there is often no feedback (much less immediate feedback), the task requires only a small portion of one’s concentration and skills, and there are constant interruptions to deal with other tasks in one’s area of responsibility.

By contrast, work in an organization where value is made to flow continuously also creates the conditions for psychological flow. Every employee has immediate knowledge of whether the job has been done right and can see the status of the system. Keeping the system flowing smoothly with no interruptions is a constant challenge, and a very different one, but the product team has the skills and a way of thinking which is equal to the challenge.

Dr. Womack, later (in an article ‘Leaning towards Utopia‘, was challenged by an evangelist that all these end up in more material affluence, not any more happiness. He ruefully agreed:

Look, the most satisfying thing in life isn’t to have wealth. It’s to be part of a creative, productive process. Even climbing toward heaven’s gate is a process. Material wealth is just the excuse for raising our awareness of the processes we’re in.

The article ends with the note: “In the end, he realized, that’s utopia – not to live in a lean world but to be preoccupied, like Dr. Womack and Mr. Jones, in helping the world we’re in get a little bit leaner each day.”

Martin Seligman, who largely revived and popularized positive psychology, led a project to compile empirical findings of psychological well-being from the perspective of positive psychology. The result is a handbook Character Strengths and Virtues: A Handbook and Classification (CSV) which describes and classifies strengths and virtues that enable human thriving and intended to be a framework for creating new interventions. The general scheme of CSV draws on six overarching virtues found across different cultures, and strengths identified under each virtue. The virtues are Wisdom and Knowledge, Courage, Humanity, Justice, Temperance and Transcendence. Each virtue has defined strengths, 24 in all.

Jump-cut to software development. Kent Beck relies a lot in values and principles as underlying foundation for XP/extreme programming practices. (Values, here, give purpose and meaning to behavior; and principles guide behavior). Some of the values and principles he endorses are courage, flow, reflection, baby steps, communication, humanity, mutual benefit, so on.

It doesn’t take long to see a pattern or similarity between Seligman’s virtues and Beck’s values. Does this mean that a well-formed XP team with solid foundation of endorsed values will have huge potential for positive psychological interventions and thus a happier existence?

Mihaly Csíkszentmihályi, father of Flow, defines as characteristics of flow activities – clear set of goals; immediate and relevant feedback; challenges and skills in balance. If these conditions are met in daily work, there’s a high chance that a person may experience flow, and, in long run, feel happier. Agile practices like sprint demos, done-done status, daily build, daily scrums and standup meetings, cross-functional teams, pair programming all align towards the criteria for flow. Besides that, such principles of team ownership, time-boxed committment, collaboration and communication, improvisations all foster optimism, adaptation, gratitude, sharing, relationships, so on. Positive psychologists (Seligman, Valliant, etc) have gathered enough empirical evidences to believe that such feelings go a long way in increasing chances of well-being.

Happiness, or rather the understanding and measuring part of it, is not as tricky as believed to be. From Kahneman’s day-reconstruction method to Csikszentmihalyi’s ESM to Seligman’s Strength Survey, we seem to have ways to assess human experiences. It will be well-worth to have empirical findings across organizations to see how the mode of working – Lean or Agile, for instance – affect well-being of people. Since we seem to have the ways, what’s remaining is perhaps the will.

Chord’ial management

You might be quick to conclude from an image of orchestra conductor waving his baton as one who is in absolute control of his musicians. But it’s not so.

Henry Mintzberg, respected writer on management, decided to spend time with Bramwell Tovey, artistic director and conductor of Winnipeg Symphony Orchestra, in order to explore how orchestra conductors came to be a popular metaphor for managers today. Instead of finding in action the words common to management books like ‘control’ or ‘directing’, he found a glimpse of what he called ‘covert leadership’ which, in fact, means:

” managing with a sense of nuances, constraints, and limitations….This is the role of the covert leader: to act quietly and unobtrusively in order to exact not obedience but inspired performance…”

(Covert Leadership: Notes on Managing Professionals by Henry Mintzberg, Harvard Business Review, Nov/Dec 98)

Whatever the media image of an orchestra conductor might be, hardly does this conductor really control. Though there might be control evident in the system or structure but all the structure and system comes from the profession itself, not from the manager. This kind of inbuilt structure makes certain rituals (like stomping their foot after a good solo rehearsal) a unconcious event for the musicians. Drawing a parallel to management of software development, that kind of tacit understanding which makes ritual (say, testing) happen is markedly absent. In music, when it comes to directing (another overused word for managers) – the experience was far from giving orders, even comments made during rehearsals have to be aimed at sections rather than at individuals.”

Lest one wrongly assumes it to be powerlessness, Mintzberg adds: Taken together, the various constraints within which the orchestra conductor works describe a very common condition among managers-not being in absolute control of others nor being completely powerless, but functioning somewhere in between.

Again before one hastens to point to ’empowerment’, he says:

Empowerment is a silly notion here. Musicians hardly need to be empowered by conductors. Inspired maybe-infused with feeling and energy-but not empowered. Leaders energize people by treating them not as detachable “human resources” (probably the most offensive term ever coined in management) but as respected members of a cohesive social system. When people are trusted, they do not have to be empowered.

He ends up with the note:

“…you may learn from this example what a good deal of today’s managing is all about. Not obedience and harmony, but nuances and constraints. So maybe it is time for conventional managers to step down from their podiums, get rid of their budgeting batons, and see the conductor for who he or she really is. Only then can anyone appreciate the myth of the manager up there as well as the reality of the conductor down here. Perhaps that is how the manager and the organization can make beautiful music together.”

Though the parallel between music and management is oft repeated, this particular paper bears to stand out from being a cliche. Still, some opines that even classical music is not a suitable metaphor for agile management which thrives on improvisation. Jazz, here, suits better.

Itay Talgam, in his brilliant TED talk, shows with video snippets the effect of ‘doing without doing’ and how

‘..suddenly out of the chaos, order. Noise becomes music’.

In this talk Talgam explains that when Karajan was asked about his mode of conducting he said “… the worst damage I can do to my orchestra is to give them a clear instruction. Because that will prevent the ensemble, the listening to each other that is needed for an orchestra”. Conductor Klieber not only creates a process, but also the conditions in the world in which this process takes place.

Benjamin Zander, leading conductor for Boston, London and Israel philharmonic orchestras; talks in his book the ‘The Art of Possibility‘ about exploring the facets of hidden possibilities. Coming back of software development, isn’t this exactly what agile methodology trying to do – to rein in inherent uncertainties with the ‘art of possibility’?

Though most of us gotta serve somebody, we can always try to take a sad song and make it better.

Shine on you crazy windows

“What do you want?” Goetz asked.
“Give me five dollars,” Canty replied.
Goetz looked up and, as he would say later, saw that Canty’s “eyes were shiny, and he was enjoying himself……Goetz reached into his pocket and pulled out a chrome-plated five-shot Smith and Wesson .38, firing at each of the four youths in turn.

Malcolm Gladwell, in his fine book ‘The Tipping Point‘ explains the Power of Context’  “is that we are more than just sensitive to changes in context. We’re exquisitely sensitive to them.” Human behavior owes a lot to the context or situation, rather than, say, personality or genetic makeup. And that explains a lot in provoking Goetz, a decent New Yorker, shoot four youths in a graffiti ridden, littered subway train in one cold december day in New York.

Power of context is best summed up by the Broken Windows theory. Gladwell writes 

“Broken Windows theory and the Power of Context are one and the same. …The Power of Context is an environmental argument. It says that behavior is a function of social context….The Power of Context says that you don’t have to solve big problems to solve crime. You can prevent crimes just by scrubbing off graffiti and arresting fare beaters…Once you understand that context matters, however, that specific and relatively small elements in the environment can serve as Tipping points …..”

Broken Windows theory is the brainchild of criminologist James Q.Wilson and George L.Kelling, and in their own words:

“Social psychologists and police officers tend to agree that if a window in a building is broken and is left unrepaired, all the rest of the windows will soon be broken. This is as true in nice neighborhoods as in run-down ones. Window-breaking does not necessarily occur on a large scale because some areas are inhabited by determined window-breakers whereas others are populated by window-lovers; rather, one unrepaired broken window is a signal that no one cares, and so breaking more windows costs nothing. (It has always been fun.)”

Kelling was later hired by New York Transit Authority, who together with subway director David Gunn cleaned up the graffiti. Later William Bratton, hired as transit police head, another disciple of Broken Windows, cracked down upon farebeating. All these attributed in bringing down New York crime radically during the mid-80s.

In order to discover if signs of vandalism, litter and low-level lawbreaking could change people’s behavior, Kees Keizer and his colleagues at the University of Groningen conducted experiments to, say, validate Broken Windows theory.

His group’s first study was conducted in an alley that is frequently used to park bicycles. ..the researchers created two conditions: one of order and the other of disorder. In the former, the walls of the alley were freshly painted; in the latter, they were tagged with graffiti ….In both states a large sign prohibiting graffiti was put up, so that it would not be missed by anyone who came to collect a bicycle. All the bikes then had a flyer promoting a non-existent sports shop attached to their handlebars. This needed to be removed before a bicycle could be ridden. When owners returned, their behaviour was secretly observed. There were no rubbish bins in the alley, so a cyclist had three choices. He could take the flyer with him, hang it on another bicycle (which the researchers counted as littering) or throw it to the floor. When the alley contained graffiti, 69% of the riders littered compared with 33% when the walls were clean.

Do the Broken Windows theory and Power of Context apply to an organization? Can we radically improve the organizational environment to foster professional behavior? Hoarding information, dirty office politics, taking undeserving credit, favouritism, all can be broken windows. Bringing right culture is a lot of fixing broken windows.

Software development is notoriously known for falling quickly into tar pit.

In the book The Pragmatic Programmer, Andrew Hunt and David Thomas look into Broken Windows in software developments:

“There are many factors that can contribute to software rot. The most important one seems to be the psychology, or culture, at work on a project. Even if you are a team of one, your project’s psychology can be a very delicate thing. Despite the best laid plans and the best people, a project can still experience ruin and decay during its lifetime. Yet there are other projects that, despite enormous difficulties and constant setbacks, successfully fight nature’s tendency toward disorder and manage to come out pretty well.”

Bad design, wrong decisions or poor code can be broken windows, which warrants fixing as soon as they are discovered. Agile development framework like Scrum is good in the way that the underlying framework makes fixing broken windows highly desirable. High order of transparency and rapid feedback mechanism with continuous integration, pair programming, daily scrums all encourage fixing broken windows.

Let the windows shine.

In defence of time

Longitudinal study is a research study in which a narrow sample segment, of humans mostly, is measured and analyzed over a long period of time. For example, a group of alpha males is observed over decades; their physical and mental attributes meticulously gathered for years, to see how they fared over time. One of the earlier account of longitudinal study is perhaps the Grant study carried out by Dr.George Valliant trying to “attempt to analyze the forces that have produced normal young men“. Journalist Joshua Wolf Shenk got an access to the archive recently and wrote about it in his brilliant essay as

The project is one of the longest-running-and probably the most exhaustive-longitudinal studies of mental and physical well-being in history. Begun in 1937 as a study of healthy, well-adjusted Harvard sophomores (all male), it has followed its subjects for more than 70 years.

So here it goes – 70 years. My idea here is to stress on the concept of time.

Marcus Buckingham wrote about Warren Buffet in his “Now, Discover Your Strengths

he turned his natural patience into his now-famous “twenty-year perspective” that leads him to invest only in those companies whose trajectory he can forecast with some level of confidence for the next twenty years.

Here – twenty years.

Jim Collins in his Good to Great talks to Level 5 leaders where it took them 20 years or so to build the strength of organization from good to great. Joel Spolsky’s Fog Creek took 9 to understand what they stand for.

Peter Norvig put the figure as 10 years when it comes to learning programming, or for that matter a wide variety of expertise.

Malcolm Gladwell had it as 10,000 hours. It applies to Bill Gates and Beatles, among others.

Classical musicians are known to train for years.

This is not to conflict with being agile or fleet-footed. Nor against bias for action. Contrary to that, it aligns. Mastery takes time. An organization culture too. It is the core which gets build brick by brick. And that core helps being fleet-footed or agile, without collecting debt.

Agile – real or placebo?

Is Agile software development just a placebo effect ? Do we get better results because we expect and believe things will get better? Or is there something more to Agile?

Linda Rising continues to enthrall us in seeing agile way of developing software in a different perspective. Earlier it was aping the ape, which gave us new insight in seeing teams.

This time she ponders if the same belief system which makes placebo work in medicine makes agile work in software development.  She believes that the belief system in agile makes many good things happen in agile.  Sheep, it seems, are the believers.

Though I found it interesting, I found it difficult to see the direct connection. Nevertheless it raised some beautiful questions which makes you think. But at the end of the day – does it matter? She says it doesn’t.

Behavioral economist Dan Ariely devotes a chapter on placebo in his book Predictably Irrational . Quote from it: “Placebo comes from the Latin for “I shall please.” The term was used in the fourteenth century to refer to sham mourners who were hired to wail and sob for the deceased at funerals. By 1785 it appeared in the _New Medical Dictionary,__ attached to marginal practices of medicine”. Dan Ariely says, two mechanism shape expectations that make placebos work, one is belief and other is conditioning.

How will a patient react if she knows she is on placebo? How will an agile developer react? If agile is offering placebo, what reason is there to believe that waterfall didn’t? After all, more managers backed waterfall than agile. If placebo is defined as pseudo-treatment with real cure, which part of agile is really pseudo?

Anyway, whatever the questions are, it’s refreshing to see Dr.Linda Rising bringing forth another interesting perspective.

In sight, in mind

A.G.Lafley, CEO of Proctor & Gamble, in his HBR article ‘What Only the CEO Can Do‘ mentions “At our global headquarters we replaced dozens of paintings by local artists with photographs of everyday consumers around the world buying and using P&G brands. All these efforts keep the two moments of truth foremost in the minds of P&Gers as they work.” An effective way to nudge the customer centricity in the people, which he refers to as “hammering home the simple message that the consumer is boss”.

Seth Godin mentions on post on dashboardsOne company put pinwheels on a VPs desk. When sales went up, the pinwheels spun faster…” (Wonder who moved whom).

Ambient makes devices which displays relevant information without being intrusive. They state “some information requires constant awareness” And then explaining the science behind it “Our brains have evolved to monitor several streams of background information without any foreground cognitive loading. Furthermore, our brains bring this information to our foreground consciousness when we discern it to be relevant within a given context.”

Taking about professions, could we have saved the recession if we had giant displays of values and ethics on banker’s offices? That  might be a stretch of fantasy. Or for instance, in software development, known for its uncanny need to herd cats, could we manage to push through the business messages better when we have writings on the wall? Or quality consciousness?

Culture called Agile

Agile is a paradigm change. Agile usually gets introduced in an organization as a new framework, new methodology, with new techniques, so on (Though, there is nothing ‘new ‘ to it) . Agile, after all said and done, is about culture. And philosophy. I am not saying that thinking in terms on framework, methodology, techniques is wrong, but we are not doing us a favour by not beginning at the beginning. This way maybe true agile will elude us.

In 90s, many organizations pretended that by ignoring the uncertainties inherent to software development, the uncertainties will simply go away. Like financial institutions pretending to ignore the black swans. So the some organizations built mammoth structure to control more and more minutely, more and more frequently. They gave an illusion of change, a false security. Meanwhile Standish group’s Chaos reports did good business.

Much has already been said about what the organization culture ought to be to nurture true agile. Definition is the easy part. The trick is in the transformation. And there you start seeing cognitive dissonance. They now have to deal with the layers and layers of concrete poured over the years. Change is so difficult. Much easier is the illusion of change. It’s not easy to unlearn gantt chart; or unlearn that actuals is garbage; or unlearn that time reporting is lame; or learn that pair programming is not waste of time; or relearn that ‘accurate estimate’ is an oxymoron; or learn that team’s and not programmer’s productivity matters.

The way to begin the transformation is to unlearn and relearn. Better to begin top down. The grassroot level, sensing freedom, might already have started changing. But there’s a lot to do there too. Years of command and control had inured masses and they wait for directions, which in the name of agile, never comes. They are deer in headlights. Mentor them to find and build ways. Teach them to own up. Show them the vision. Empowerment never can come if all one sees is laying bricks and not building cathedral. Clichéd metaphor, I know. Steve Jobs once famously hired John Sculley from PepsiCo asking him ” Do you want to spend the rest of your life selling sugared water or do you want a chance to change the world?” . That is showing what vision is. (It is another story what Sculley did to Jobs later).

The managers by then should start building the right culture. But culture gets build brick by brick, over sometime decades. One can also start coaching  the right philosophy. Build the practices to support the philosophy. Build the techniques to support the practices. Use the tools to practice the practices. If you start at practices ignoring the culture or philosophy part, people  might be left standing with the why? questions. And they will end up in laying bricks, not building cathedral.

It’s all in culture. Right culture will spawn the right process. Right process will spawn the right techniques. If it doesn’t happen, look back at the culture, it might be broken. That way, anyday I will prefer ‘waterfall’ with right culture than so called agile with a wrong one. Scrum is after all the framework to help you reach that level of excellence.

Influence of Organizational Stucture on Software Quality

Messrs Nagappan, Murphy and Basilis’ paper on influence of organization structure on code quality caught my attention when was recently mentioned in infoq.com. (Though the paper is not recent, it is published in Jan 2008.)

The paper describes how organization structure affects software quality. Organization structure attributes can be used to build a prediction model for assessing software quality, or to be specific – failure proneness. In authors’ words “In this paper we present a metric scheme to quantify organizational complexity, in relation to the product development process to identify if the metrics impact failure-proneness.” Eight metrics were derived for organization structure. (Though it was difficult to understand how ‘edit frequency’ can always mean instability or low quality code. Think, a developer with healthy habit of continuous refactoring can skew the data.) The guinea pig was Windows Vista with 3404 binaries and 50 MLOC, seemingly the largest such study in commercial software. All data goes through a menacing logistic regression equation to spit out failure-proneness of binaries. This in turn is used to calculate Precision and Recall for pre-defined random split. And out came the numbers. The average precision value was 87% and average recall value was 84%.

Which means 87% of all binaries that were predicted to fail actually did fail. And 84% of the all binaries which failed were predicted beforehand. (It took me some time to understand the difference). Compared to other prediction models like Code Churn, Code complexity (they cited 5 more), the results are shown to be more predictive.

The authors, quite humbly, didn’t rush to propose any prescribed crystal ball model. But one cannot help wonder how this fits together with other factors which are already known to influence code quality, like quality of developers. That means if we keep the org structure same (say a control group) and change the quality of developers, by this model the failure-proneness stays the same, but we know that’s not the case.

The findings were quite interesting, perhaps important too, though this paper, even for a technical one, wasn’t a good read. Sometimes the sentence construction jarred and seemed prone to be misinterpreted or chuckled. (“NOE is the absolute number of unique engineers who have touched a binary and are still employed by the company” or “OOW is the ratio of percentage of people…”. But that’s my nitpicking, apologies). The paper mentions generously other papers which have carried work in similar vein. The references run 37 papers.

It is indeed promising to see that the authors plan to conduct this line of research for open source models where the organization structure is very different in being distributed and non-hierarchical. Similar research on open source might reveal a lot which can be used by other organizations (Open source itself is not likely to benefit from the results, though).

Outsourcing companies specializing is building software/solutions using delivery centers in low cost geographies will benefit the most from such studies. The findings will help clients realize the cost associated with or risk entailed on software quality with distributed development. It will also make sense for agile teams, which once fancied collocated teams, and now getting more distributed.

It might be possible, with enough studies, to suggest an organization structure for minimum failure proneness. But it seems to be a tall order.

[This paper is also being written about here and here.]