What's the bottleneck for software development? More directly, what's the area that is important but takes the a lot of time and if it was sped up would decrease total development time? I'd have to say it's project quality.

If project quality is in check, the project is in a better position to release at any given time. Shipping the software is a primary goal of software development. Even if you aren't following XP's iterative ship early, ship often approach, ask yourself "is this task getting me closer to shipping the product?" If it's not, question why you're even doing it.

Another reason project quality is important is that it's much easier to refactor and add features to well tested code because you'll know if you break anything. This puts you in a position to augment with confidence.

Without unit testing, you are adding code entropy without a safety net every time you touch the code: you are stirring up the codebase and adding defects. I don't care how good of a programmer you are, you will add defects when you add features. It may seem like it's much faster to add features this way, but it's a trap. In the long-haul the develop now, test later approach takes much longer to add features and make sure they are good enough quality to ship. You're going to have to do the quality work anyway, why not do it now?

So let's see ... how can we improve software quality? Unit testing is a good way, and if you go even further you can do test driven development. Developers sometimes resist this approach because they see testing as grunt work. This is old school thinking, and developers like this won't help your project -- they will hurt it. They are not thinking of the project, they are thinking of themselves.

Another way to improve quality is to throw people at the problem. This may seem like a stupid idea, but this is why open source projects succeed: the project managers leverage everyone that uses the software. You have to channel this feedback properly, organize it and get the feedback to the people that can make the changes but it seems to work really well. Using feedback is absolutely critical for success.

In fact it works so well in the open source world that it's seen as a viable replacement for unit testing on small projects. I don't completely agree with that sentiment, but having an army of free testers is better than nothing. The interesting side effect is that if you're not unit testing an open source project you can get new (but initially lower quality) features into the codebase faster, attracting more users on the bleeding edge and then the project sometimes just snowballs. Quality is improved by listening to feedback. You walk a fine quality line, but you have to in order to respond to feedback quickly and attract more users, which improves quality. It's very cyclical.

Taking in and using the feedback isn't the hard part. The hard part is finding the people. On open source projects it seems to be a combination of the project's usefulness and the project manager's charisma and communication skills. On closed source projects users are much harder to find.

Number one, they usually cost money. Number two, you can't just use anybody to test your product because it might be a secret, so you need to test in house. Number three, your developers are biased and are poor testers by nature -- they can only do so much. All of those factors narrow your options. Closed source projects can't compete with open source projects' army of free testers, so they need to improve quality in other ways.

Planning a project up front (ie. waterfall) is a defensive style that can improve project quality at the expense of agility. If your company can live with this, then it's a good way to go. Iterative/agile approaches also seem to produce good results. They use customer feedback with iterations and unit testing to allow for high quality but agile code that can respond to change ... at least that's the theory.

So back to the bottleneck issue now: how can we speed up project quality? I think there's lots of opportunity to improve testing tools, even just improving how we look at the tests themselves so that their effectiveness may be analysed easily. Continuous integration also helps to keep the project on track, and gives the project manager good feedback.

Code coverage tools like EMMA also help the testing effort, pointing out weak areas and making sure important/sensitive areas are well covered.

Couple that with more effective feedback management and defect triage and I think you'd speed up the whole development process a lot.

Someone is going to make a lot of money improving the testing experience. There's a big gap here and lots of opportunity.