Frank, >Traditional measures, huh?
Well the ideas go back to the late 70's. But people have only being calculating what look like meaningful numbers for the last 8 years or so, "Using design cohesion to visualize, quantify and restructure software" by Kang & Bieman, Technical Report CS-96-101 from Colorado State University is a good guide. > So, when was the last time you actually >*measured* the coupling or cohesion in any program you wrote? Until recently never. Without some mathematics behind them the ideas were just that. Once a way of calculating cohesion & coupling became available, people could write tools. See "Architectural repair of open source software" by Tran, Godfrey, Lee and Holt (I don't have a journal reference, I downloaded it from somewhere on the web). >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. You might not expect it, but wouldn't you like it have it? Ok, so software evolves. Buts lets at least try and make an effort to start out with good interfaces. >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. I agree. But I am not aiming for optimal. I am aiming for consistently not bad. Also my measure would include learnability as a factor. It would not be driven purely by architectural demands and niceties. > 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. This is an issue that is not likely to be answered in the short term. What manager would be brave enough? > 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. Ah, the "Good programmers will ..." argument. My argument is that there are so few good programmers that source needs to be written so that it can be worked on by the not so good. Now in 25, 50(?) years time when software development has settled down a bit and demand has subsided sufficiently that companies stop hiring anybody who can spell C, a degree of professionalism might emerge. We can start assuming that programs are going to be worked on by good programmers. derek -- Derek M Jones tel: +44 (0) 1252 520 667 Knowledge Software Ltd mailto:[EMAIL PROTECTED] Applications Standards Conformance Testing http://www.knosof.co.uk - 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]
