A good (experienced) programmer should eventually have a good 'feel' for how much time certain tasks take (but having domain knowledge does help too), and the scrum planning poker is a way to get to such an estimate, but it is of course not perfect. Very important is a proper brake down of the tasks (not forgetting any tasks). Many developers under estimate the time it takes to write some code and provide proper unit tests for the test team, this results sometimes in going to the other extreme and estimating too much time. Another approach is to look at historical data of your developers. This guy wrote a case study that uses historical data of his developers to estimate future tasks : http://vanlingen.name/web/cv/unpublished/article/2010/02metrics/metrics.pdf It is an interesting approach, but I would not only rely on that. A combination of techniques: historical data, estimation by developers, good task breakdown (not forgetting tasks), I think is needed for estimating the time it takes to complete a project.

Of course this is not surprising if you assume most of its users are in same timezone and do their work between 9-17. Clouds only work if the work of its clients is distributed over time, you can then aggregate dedicated resources for tasks. A cloud can not (never) properly deal with socalled peak load without making sufficient investments into hardware. Peak load occurs when everybody start using the system at the same time for intensive processing or data transactions. This is more likely to occur if your users are in the same timezone. So if your are looking for a 'good' cloud I suggest also looking at the user list. If the users are sufficiently distributed over different time zones it might scale better (this is of course not the only criteria for a good cloud). I myself prefer 'Thunder clouds' :)

And it shows. I work with physicists both at CERN and Fermilab (the latter potential hit hard by the new cuts), and know from experience that especially people employed by American universities/labs are looking around for jobs due to ongoing (recent years) funding uncertainty. Most of them love the work they do but for many of them it is an issue of more (financial) stability for them and their family. John