IMHO I think that adding this mark thing for each class doesn’t add value to programmers. Instead it sounds like a way for some manager to take a look and get some virtual numbers on how “well” the programming is going. By introducing this marking system you are adding quite some overhead.
Instead I think it is better to base the level of completion on how well the module/classes meet the requirements.
This can be measured by doing the tests first and then developing the module/classes until the test is fullfilled. I have had good experiences with this approach.
just my 2c
br/Anders.
…
Bob wrote:
Hi Peter,
Good idea! It would be helpful for new comers to know, what can be improved, where the work is.
But my question is, who is responsible to give the mark for the classes. If different people have different filling of quality, who is going to decide the mark?
Another issue is, how many classes Calitko has. Is it too much work to give all classes marks? Or can we mark modules?Best regards!
Bo
Peter Dimov wrote:
Hello everybody,
I was thinking about how we could have a good measure of how much we are advancing with Calitko. There are undoubtedly at least two measures: quality and quantity. I think we could do an approximation of our overall progress by measuring the change of quantity and quality between releases. When we are adding new classes to solve new problems we directly increase quantity and very likely reduce quality. That will normally be the case because the new code will not be fully functional, not fully tested and not fully documented. When working on existing classes we should expect an increase in quality as functionality, tests and documentation get improved.
I’d propose that we start marking each class with values from 1 to 5 for example (just randomly chosen, we can change them). We could use this as an overall marking for the class, or have separate ranks for functionality, tests and documentation. When somebody is doing code review, one should mark or validate the marking of each of the inspected classes. The evaluator should write in the class docs header what are the problems and what can/should be improved. Once we get Trac (http://trac.edgewall.com) setup for Calitko with Bazaar, the evaluator could also create a tickets for the identified issues.
I’d be expecting some interesting ideas from you guys!
Best regards,
Peter