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':)
Although the 80 columns rule has a historical reason, I find it most of the time more than enough.
Having reviewed code that violated the 80 columns rule frequently I noticed 2 things:
-variable names where too long
-decomposition of the program into components or classes was not done properly.
Basically : sloppy code.
In my experience the 80 column rule adds to some discipline in writing code that is also readable
to others (although some people still screw up) just as other conventions for variable names, class
names, etc...
Perhaps if we all work with fancy IDEs you might argue that you do not need the 80 columns rule.
However I have not seen many IDEs that can replace simple editors like emacs or vi (some might
argue that emacs is not a simple editor).
Finally I might have my 2 times 1900 by 1200 pix. screen in my office but others have not so 80 columns
is a save size. Granted it is still somewhat difficult to read 80 column code on you PDA or cell phone.
Slashdot Mirror
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' :)
Although the 80 columns rule has a historical reason, I find it most of the time more than enough. Having reviewed code that violated the 80 columns rule frequently I noticed 2 things: -variable names where too long -decomposition of the program into components or classes was not done properly. Basically : sloppy code. In my experience the 80 column rule adds to some discipline in writing code that is also readable to others (although some people still screw up) just as other conventions for variable names, class names, etc... Perhaps if we all work with fancy IDEs you might argue that you do not need the 80 columns rule. However I have not seen many IDEs that can replace simple editors like emacs or vi (some might argue that emacs is not a simple editor). Finally I might have my 2 times 1900 by 1200 pix. screen in my office but others have not so 80 columns is a save size. Granted it is still somewhat difficult to read 80 column code on you PDA or cell phone.