Outsource Software

Agile methodologies are becoming more and more popular today, especially for small startup groups. Though I’m sure there are much larger organizations that have achieved success with its strategy I can see smaller projects jumping on it much quicker.

To the project team itself agile methods might look great, but convincing management and people that talk business sense it is a good thing is often a much harder process. I find this interesting because one of the main focuses of agile is to place the quality of software over everything else. As a primary metric, agile and agile meta models (SCRUM for example), focus on making maximum business sense or providing maximum business value at the end of every iteration.

Ok, so agile makes it a standing point to deliver on what the customer wants at the end of each iteration, but what are the other motivating factors behind pushing agile as a model for delivering real business value.

An improved feedback and control loop

Agile provides its clients with frequent opportunities to provide feedback at the end of an iteration. With this, they can further direct the project in an incremental fashion, driving the next iteration with their business sense, asking questions like “What is of most business value to me right now?” This iterative feedback from both the client and project team lead to advantages that would otherwise not be available, jumping on new and upcoming technologies and developments to spearhead the next iteration.

These changes and developments have the effect of spearheading the project towards success and an overall better product. In some cases, it can provide improved return on investment by allowing the product to be deployed much earlier. Remember, an iteration focuses on delivering the most business value it can. If there is enough of that value there, enough to make this business sense just that, it is worth deploying early to start recouping on costs before the product has even reached the end of its development life cycle. By the time the project has come to completion, you may well have recouped half of your initial investment.

Avoid catastrophes

It’s common for a project to be tracking well and suddenly fall behind at a late stage in development. Why? Traditional software development life cycle models find it much harder to judge the correctness and completeness of up front analysis and design. This lack of information sometimes leads to overly optimistic views which don’t manifest until much later in the project when it is too late to do anything about it. Do you cut your losses and get out? Or take the risk? Well, another way to look at it would be to avoid this risk altogether. And by avoid, we really mean circumvent. As an iterative model, agile performs short bursts of analysis, design and implementation often. This gives rise to much more tracking data before entering the next iteration to re-evaluate where the project is at and if it is still on track.

The only four variables we really have control over in software development are: time, scope, cost and quality. Having the advantage of a model closely tied to these variables often and right throughout the projects life cycle is a big risk mitigator.

A focus on quality

This is a major area of agile models and comes back to core concepts known as the agile manifesto. It is basically saying; focus on quality software that translates into real business value for the customer each step of the way. Deliver this value at the end of each iteration, even if it means less formal practices and documentation is kept. Use customer collaboration as an improvement mechanism and embrace any change that might be coming.

Like extreme programming agile also adopts the practice of pair programming. No discussion on “What makes good business value?” or “What brings good return on investment?” would be complete without talking about it. It’s often hard convincing management that using two people on one task is beneficial. The productivity of having two people on one task is slightly lower than each working individually (I’m not going to make up any fancy statistics here:)). So this would raise the argument that pair programming actually costs more! What you cannot as easily measure however is the increase in quality pair programming brings.

Agile promotes information sharing

All information is shared amongst team members, often with the activities being shared to: analysis, design and implementation (pair programming during development for example). This information loop routinely filters through to the customer too. After all, that’s why they are there, to provide input going into the next iteration.

Agile development however is not necessarily well suited to all types of projects. Sometimes no matter how hard you try you just cannot come up with a good enough business reason to justify the model. That’s fine, agile does not suit every type of project small and large. Just recognize when you might be able to gain the flexibility and momentum it offers.

“Software Engineering” - Whatever That Means
If a programmer hands you her business card, it probably won’t list her title as “Programmer;” It is more likely to read “Software Engineer.” This raises the interesting question: does a programmer’s daily job rise to the level of an engineering discipline? I think it would be more accurate to call programming an emerging engineering discipline.

Evolution of the Field
Since around 1975, various people have tried valiantly to impose discipline on the chaotic, egocentric, idiosyncratic practice of programming. And just at the turn of the century some professional institutions have started to establish the core competencies that would let a programmer call herself a software engineer.

Vision of the Future
Will we see the transformation complete: will programmers be licensed and regulated like other engineers? Personally, I think it’s too early to bet one way or the other - programmers are remarkably individualistic and there will be be very strong resistance to regulating what they regard as their craft. On the other hand, offshore development and the rise of software-based lawsuits are changing the landscape much as barbed wire changed the American west of the 19th century. If you’d like my prediction, ask me again in a decade.

Today’s Situation
But if you are going to work in the world of the programmer, you’ll have to understand some of the standard ways in which complex software is constructed. If you want to sound erudite, you can refer to them as “software development methodologies” or “development models,” but if you’re talking to a programmer you’re better off asking, “So, how do you folks build software around here?”

Pair programming: People either love it or hate it.

The concept of pair programming first became popular thanks to “extreme programming” or XP—a set of practices that supposedly allows companies to develop software in a more efficient, more “agile” manner. Proponents of XP claim that it allows programmers to respond to changing or ambiguous software requirements without sacrificing quality. Skeptics disagree, arguing that these alleged benefits are either illusory or exaggerated.

XP proponents argue that two programming heads are better than one—that two software developers working together will tend to produce better, more reliable and more maintainable than a single programmer working alone. This practice is known as pair programming, and at first glance, it sounds like a great idea. Personally though, I think that it smacks of a “one size fits all” mentality. That is, it assumes that two programmers working in concert will indeed be more efficient and that they will produce better results. I think there is good reason to believe otherwise.

The much vaunted Williams study

XP fans typically point to an infamous study headed by Prof. Laurie Williams at the University of Utah. In this study, Williams concluded that pair programming takes 15% more time than solo development, but results in software that is 15% better. They argue that this modest increase in development time is a small price to pay, since better code quality means that less time and effort will be required later down the road – during testing and maintenance, for example.

I think that there are numerous problems with this study, though. How did the researchers gauge software quality, for example? The used the length of code as the quality metric; that is, the shorter the source code, the better they deemed it to be. The reported, “[The paired teams] consistently implemented the same functionality as the individuals in fewer lines of code. We believe this is an indication that the pairs had better designs.” I think this is a hasty leap of logic, to say the least!

Does shorter source code exhibit greater quality? Sometimes, perhaps. However, one could just as easily speculate that the longer code contains more bug fixes and safeguards. In addition, adding more code lines – to implement a design pattern, for example – can make the software more efficient or easier to maintain. I think that the presumed correlation between code length and lack of quality is poorly justified at best.

The study also exhibited a severe case of participant bias. The students in a class were asked if they preferred to work in groups or alone. 35 of the respondents said that they preferred collaborative working; of these students, 28 of them were selected to constitute the pair programming experimental group. The remaining seven were placed in the solo programming group, i.e. the experimental controls. This created a strong experimental bias; all of the pair programmers were willing volunteers, whereas some members of the control group were there reluctantly.

What’s more, 13 out of the 14 pairs were self-selecting; that is, students were allowed to pick their partners willingly. Once again, this biases the results, since participants are likely to select partners with whom they are particularly compatible.

(Interestingly enough, these biases could have been easily avoided by assigning pairs randomly. I don’t wish to cast aspersions; however, I can’t help but wonder if Prof. Williams and company might have unconsciously biased their experiment to demonstrate the superiority of pair programming.)

Short-circuiting the creative process

In short, the supposed evidence for increased productivity under pair programming is questionable at best. In addition, we should ask if there’s any reason to believe that pair programming can be counter-productive or otherwise harmful.

I believe that it can be. Pair programming can certainly help people catch or prevent bugs; as the story goes, two pairs of eyes are better than one. When faced with a thorny problem though, one often needs to let the problem percolate in one’s brain for a while before arriving at a proper solution. Often, that’s how creative minds operate; they need to let their minds sift a problem first before attempting to fix it.

With pair programming though, this process is short-circuited. Instead of letting one’s mind digest the problem in due time, pair programming puts pressure on people to arrive at a solution more quickly. Sometimes, this may produce better results; however, it can also have the opposite effect. I suspect that for the most creative minds, this kind of pressure can stifle creativity rather than hinder it.

But wait! Isn’t there power in numbers? Aren’t there times when the best results are produced by having people brainstorm and confer? Certainly… but these “meetings of minds” don’t have to occur during the programming process. They can occur during planning sessions, during design reviews, or when sitting around a lunch table. We shouldn’t dispense with group troubleshooting and design; we simply shouldn’t force this to occur at the coding stage. That can do more damage than good.

What’s more, the most creative minds often need a measure of playtime – an opportunity to play around with the code, tentatively exploring various options and letting one’s mind roam free. This can be difficult to do when another programmer is looking over your shoulder. After all, what should we do – explain and discuss every tentative step? For a creative mind, this can be stifling indeed.

Conclusion

In short, I think that the evidence for pair programming effectiveness is questionable and overblown. I also think that there’s good reason to believe that pair programming can stifle the creative process, instead of helping it. Can pair programming be helpful? Certainly… However, when forced upon people, it becomes a “one size fits all” strategy—and unfortunately, a single size can’t possibly fit everybody, no matter what the salespeople say.

If you have been implenting or considering Agile Software Development Process with Offshore Software Development Providers, this article from Martin Fowler, might be interesting to you.

An excerpt

For the last four years ThoughtWorks has operated a lab in Bangalore India to support our software development projects in North America and Europe. Traditional approaches to offshore development are based on plan-driven methodologies, but we are very firmly in the agile camp. Here I discuss our experiences and lessons learned in doing offshore agile development. So far we’ve discovered that we can make it work, although the benefits are still open to debate.

Agile Software Process with Offshore Development