Derek M Jones wrote: > What I am suggestion is that the traditional measures of coupling & > cohesion are of secondary importance.
Traditional measures, huh? So, when was the last time you actually *measured* the coupling or cohesion in any program you wrote? I'm happy just to use these as concepts that support the judgements that I and my colleagues make about how to organise software. We seem to agree well enough most of the time, and seem able to make sense of software written by each other, as well as software written by people we've never met. Of course, we also rely on other things besides what we were taught in school, and we have strategies for resolving disputes, dealing with inconsistencies, and working around poor designs when we can't change them. I don't expect libraries and classes and file systems and protocols all to be well-designed, nor do I expect there to be some collection of metrics that they've been optimised for. Although such quantitative analysis has its place among the activities of experienced programmers, I certainly don't believe you can glibly measure quality into software, nor methodologise it towards easier learnability by The New Guy Who Might Quit Soon Anyway. Not in a month of Sundays would I think there was one 'correct' or 'optimal' way to design software of any significance or scale, especially if it was expected to endure and develop over time. > With typical developer turnover of 25% a year and hundreds of > external identifiers, learnability is the major issue. So, based on this figure, 75% of developers stay put each year. Hmm. Why are their needs less important than those of new hires, especially as familiarisation with a new project is just a short-term need at the start of a new job or contract? > I think most managers would be willing to put up with howls of > protests from experienced developers, that identifiers were declared > in the 'wrong' module, if it meant that the developer could quickly learn > where things were. Any managers who provoke howls of protest from experienced developers will quickly find themselves only managing new hires. Perhaps I understand your concern with the short-term needs of new hires now, but I fear it's not for the right reason. Good programmers will be able to provide reasonable suggestions for how to improve the quality of their work, and good managers will act on what they say, rather than trying to shoot at the programmers with silver-plated bullets. > When I visit a new town I want to be able to find my way around easily, > not be confused by some other persons conception of what is 'logical'. Might I politely suggest that you either get a good map, befriend a local or confine your travelling to Disneyland? The needs of tourists don't outweigh those of residents, even in a city like London. Similarly, the short-term needs of someone who hasn't been hired yet are less important than the long-term needs of people actually working on existing projects. Additionally, if all you see are things that are already familiar to you, what chance is there that you'll learn something new? > The problem with OO is that there does not seem to be agreement > among the people claiming to be experts. Given that the field has > only just turned 10 I don't think anybody is much out of class 101 yet. On the contrary, I believe that disagreement between experts is merely the sign of a complex field. Look at the practice of medicine; doctors often disagree on the best course of treatment for a patient, but it's not taken as indicating that one doctor is 'correct' and the other's 'wrong'. It's just a side-effect of different experience, different education, different patients and a diverse choice of options for treatment. The more difficult the condition, the more choices of treatment plan you might get. Funnily enough, they might all work! Consequently, I'm not waiting for all doctors to start agreeing about all their treatment plans, any more than I'm waiting for all programmers to start organising their software the same way. -- Frank Wales [[EMAIL PROTECTED]] - Automatic footer for [EMAIL PROTECTED] ---------------------------------- To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss To join the announcements list, mail [EMAIL PROTECTED] subscribe announce To receive a help file, mail [EMAIL PROTECTED] help This list is archived at http://www.mail-archive.com/discuss%40ppig.org/ If you have any problems or questions, please mail [EMAIL PROTECTED]
