Next-Gen Tools in Global Software Development

Another link from Barney's: Barney Pell's Weblog: VC Taskforce on Next-Gen Tools in Global Software Development. The topics covered with Barney's great notes are the risks of outsourcing, getting requirements wrong (a costly problem made worse in distributed development), and investing in software tools.

Some of Barney's big takeaways from the panel discussion:

• Individual programmer productivity is always nonuniform. Some programmers are 10 or even 100 times as productive as others.
• The results of outsourcing are often disappointing
• A recurring theme in the panel was the difficulty and importance of getting software requirements right. Despite all the improvements in tools and processees for developers, there have been limited improvements in the way people create and validate the requirements in the first place. Errors in requirements ripple through the downstream flow and get more expensive to fix the later they are caught.

I contend that a good user-centered design process that starts during requirements gathering will achieve the results that are wanted, assuming the business has a goal that's addressing a real user need. A good designer helps bridge that communication gap between business analysts and "the IT folks who got it wrong." More of Barney's notes:

"Do your business people and IT people understand each other? Answer to this is usually 'no.' The problem: Missing, ambiguous and contradictory requirements. 60-80% of project failures can be attributed to requirements errors. at the very front of the process. not the arch, dev, or testers! The biz people say you didn't understand, the IT guys say you didn't explain. Scope creep and rework usually mean you didn't find the errors it the beginning; Good requirements are hard. Requirements definition and validation cycle: informal primarily text requirements -> spec -> formal spec documents -> validation -> visual inspection and review of spec for errors -> elicitation. This is a laborious process, with error detection that's bad."

Almost every usability practitioner in industry or consulting moans about "not being involved early enough." That moan is usually because the problem is with the requirements, on a project that's already made it to the point where it's too late to change direction....