--Originally published at TI2011 – Miguel’s Blog
For this second partial, we finally get into the main thing I had been waiting for, the actual experiment starts. There were some unexpected conditions by Belok, but thankfully everything worked out at the end. The first problem Tompkins and his group faces is that Belok wants everyone to be on the same team. Overstaffed teams are a bad idea when it comes to software development, 2 people won’t write twice the lines of code than just one. As you start adding more people to the project you start seeing diminishing returns until you actually start losing productivity and money by adding more people. With more people conflicts will form more easily and in some cases there might not be enough work for everyone so you are paying people to do nothing and just wait until there is work for them.
The book also talks about function points, which are a way of measuring projects. However, Tompkins and his team realized that they didn’t really need function points, they could just have come up with an arbitrary unit of measurement that worked for their projects specifically. After that, we revisit the problem that you can’t increase productivity in the short term. Tompkins is demanded to follow the Capability Maturity Model which will only increase productivity in the long term and will actually increase the time it will take for the 6 projects to finish. We also learn about other ways that programs like CMM can be detrimental. For example, CMM sets such a strict set of rules that you are not allowed to stray from the path, even if you find a faster solution. In this case, since the 6 projects are copies of other projects, the managers wanted to use the documentation that was already done before and have Continue reading "Partial Reflection 2"
