Colin Paul Gloster writes:
Dear William,
In response to Bill Fishburne's example comments for a stack in his article `Comments Considered Good' in the August 2006 issue of Overload and his claim that "The comments offer us something that code alone cannot. There is no way for the declaration to state that size will decrease by 1 as a side-effect. [..] the code cannot document itself, particularly in side-effects", I really do not agree with this. Postconditions and the Design by Contract™ paradigm are capable of documenting this without a comment, e.g. SPARK [ SPARK ] and Eiffel [ Meyer ] can do so. (SPARK is defined in such a way that it is entirely written inside comments of another language's. This does not affect my point that postconditions in SPARK are documented without a comment: the commenting is for bypassing the other language's compiler, before the other language's compiler is invoked the SPARK code must be passed by a SPARK analyzer.)
Regards,
Colin Paul Gloster (Colin_Paul_Gloster@ACM.org)
[ Meyer] Bertrand Meyer, 'Part 6 Design by Contract and Assertions' of 'Invitation to Eiffel', http://Docs.Eiffel.com/eiffelstudio/general/guided_tour/language/invitation-07.html
[ SPARK] Praxis High Integrity Systems, 'SPARK Quick Reference 1 - Toolset and Annotations', www.Praxis-HIS.com/sparkada/pdfs/SPARK_QRG1.pdf
William Fishburne replies:
Colin,
Thank you for your comment. I was speaking particularly in respect to C/C++, and am sadly unfamiliar with both SPARK and Eiffel (I know Eiffel by name only). It does seem likely, however, that any language which could completely forego comments would be so verbose as to rival a native language (such as English), although I would surely not want to bet the farm on it! One might argue that `side-effects' would be impossible in such a language, but I will let my ignorance of the two languages in question strongly undermine the validity of any such argument from me.
Instead, let me direct you to http://www.ddj.com/184405997 which is an article by Christopher Diggins who built Heron using the Design by Contract paradigm and stated (with respect to the paradigm and not specifically to Heron):
In fact, some pre/postconditions are difficult and even impossible to express in a formal language. In these cases, the pre/postcondition is best expressed as a natural language comment.
I'm unable to evaluate the validity of this assertion, but simply point you toward it as it seemed relevant to me.
William Fishburne (bfishburne@gmail.com)
Colin Paul Gloster again:
Dear William,
I do not know of any programming language in which comments are not possible, but I can think of at least one terse specification language (namely Z) which does not have comments. The objection I have written is not against the overall idea that comments may be good, but rather against a specific example in which it had been claimed that code visible to the user other than a comment can not document a particular feature.
I agree it [the Christopher Diggins quote] seems relevant. Not everything is expressible in every or maybe even some language, and a comment may be helpful to explain something complicated which is written or which can not be written in a formal language.
Regards,
Colin Paul Gloster
Seweryn Habdank-Wojewódzki writes:
Dear Rachel Davies,
I read your article about Pair Programming [ Overload 73 ]. Last month I made a survey of software projects. I would like to share my observations with you.
The survey was of 48 software projects. A questionnaire was completed, recording metrics such as the number of lines of code, the number of developers, the number of different languages and APIs used, and so on. A copy of the questionnaire can be made available if desired.
In figure 1, I show cloud data which shows a correlation between complexity of the project and the number of developers.
|
| Figure 1 |
This shows the trivial fact that as complexity increases, the number of developers increases. We could also turn this round and suggest that more developers can spontaneously increase the complexity of a project.
One other interpretation we can make is how much complexity can the average developer cope with? This appears to be around 1 developer for 5 points of complexity. This might be useful for managers in estimating how many developers are required for any particular project.
Figure 2 shows the number of lines of code per person month, plotted against the number of developers on a project. Looking at the top of the graph, we can observe that there is small tendency for developers to create less code as the numbers of developers in the project increases. On the other hand, looking at the bottom, the least productive developers create more code as the number of developers increases.
|
| Figure 2 |
This may be because, as team size increases, developers spend more time on communication between themselves, but conversely they are stimulating each other to increase speed, possibly because a group of people is more creative than the individuals alone.
Figure 3 shows the number of lines of code per person month against the duration of the project in person months. It shows that coding speed decreases on a longer project.
|
| Figure 3 |
There may be two reasons. Firstly, to get a high number of person months, there may be many people on a relatively short-running project. Many people need more time to communicate, instead of coding. Secondly, a small group of people may work on a long-running project, develop a large codebase, and they cannot cope with it, perhaps through boredom or tiredness. This would suggest that programmers are better when they are new in the project, but of course there is a low boundary, as it takes time for a developer to attain good productivity.
Figure 4 shows number of lines of code per person month against project duration (only data for projects between 20 and 30 months duration are shown). As can be seen, as project duration increases, coding speed slows.
|
| Figure 4 |
My question is how do you think Pair Programming would affect the results - would the same trends be seen, or would pair programming projects correspond to the same graphs?
Best regards,
Seweryn Habdank-Wojewódzki (habdank@megapolis.pl)
Rachel replies:
Dear Seweryn,
I apologize for taking so long to reply to your questions. I have looked through your observations and the graphs are interesting.
Your conclusions on how much complexity a developer can handle make the assumption that the project did deliver/complete and that developer competence is a constant. Your survey did not ask is what calibre of developers were used and also whether the project delivered to completion. In my view, the graphs only tell us is the level of staffing that the organisation felt was appropriate, this might depend on other factors not just complexity ( such as how much money is available, expected working hours, number of developers already in department, etc.). Also, I am also not sure that having a coding standard or doing testing (questions 11 and 12) increase the complexity of the project.
Regarding the other pictures (developers-lines of code), I would add that I do not expect lines of code to keep growing at the same rate throughout the project. I would hope that the team practice refactoring and have an on-going effort to reduce code bloat in favour of cleaned up designs. In this study, we don't have information on other factors that could be affecting developer productivity (company events, time spent in meetings, etc). I don't think lines of code is enough to assess developer productivity. I think you need to combine information about code quality and customer satisfaction to understand if these developers were truly productive.
I am not good at speculating but would hope that pair programming would improve code quality and if that were factored into your measure of productivity then pair programming ought to improve productivity but have a slower rate of adding code due to more emphasis on refactoring.
Best regards,
Rachel Davies
