> It's just that Something that improved the capture of requirements by > 0.5% > is more likely to have a significant impact on the outcome of most software > > projects than improving the readability of code by 300%.
>Not wishing to be funny or anything, but how do you know? And taking your statement >at face value, suppose the figures were 0.2% and >450%? What then? Since no one seems to be able to present any numbers on the impact of readability on software projects, as versus, reading snippits of code, I'll just have to go with my own personal experience, bolstered by the claims of other research that requirements problems have the greatest impact on software productivity. If you look at estimates/data on where the effort actually goes in a software project of more than classrooom size, the parts of the project that involve reading/looking at/modifying the code are fairly small. Effectively, this presents an upper bound on what readability improvements can accompish. (Yup, I'd still go for the 0.2% over the 450%.) >To me, the outcome of most software projects is continuous, not discrete. The longer >development flows, the more likely it is that stuff >downstream from the >requirements-gathering phase (such as, say, fixing a problem or adding a feature) has >a noticeable impact on the project's pool of users. Especially when the code so >unreadable to the next bucket of programmers on the job that it's more productive to >redevelop than to suffer their attempts at modification. I don't understand the phrase, "downstream from the requirements-gathering phase." Requirements gathering happens continuously throughout the life of a software product. If nothing else, backward compatibility with old versions of your own product becomes a requirement for the next version. Requirements don't even stay fixed for one software release; the requirements to be met at initial project design time are never the same as the ones you have to meet by the time you reach release testing. The only product that has a fixed set of requirements is one that is no longer being used. I can imagine that there are companies that have employed hoards of inexperienced or poor quality programmers and have ended up with code that is so unreadible that it is a major impediment to productivity. Since it's been a long time since my company has done a lot of hiring, the biggest problems I face when I read code are understanding what the original requirements were, not reading the code. Why is the code trying to find out whether "process01234" is running? (Because our customers used to use the FooBarTwonkie 2.3 driver which, unbelievably, failed to intialize the message buffer; most of them have now upgraded to FooBarTwonkie 9.0 but who knows what's still out there?) I'd happily read pages and pages of monocolor code in upper case, in a fixed width font with or without underscores, in exchange for a simple comment (or link to a requirements management system)that explained to me what was going on. In the companies I've worked for, I've yet to hear of a case in which a major re-write was done for purely or primarily code readability reasons. Almost invariably, the reason has been a major architecture change, either because new capabilities became available in the software environment or because there were new major requirements to be addressed. (Actually, the only project I know of for a re-write that was based on primarily on new software capabilities got cancelled because they couldn't explain to management how this would benefit customers.) It used to be the case that people estimated that 20% of the effort in software projects went into actually writing the code. Nowadays, that number is probably even smaller when you consider the amount of time software developers spend in word processors, specification tools, email, project management tools, defect tracking tools, test tools, and configuration management tools. Writing the code is almost something you do for relaxation in the evenings. Perhaps that's why everyone is so interested in programming editors - they are used in the one part of software development that's still really fun! Ruven Brooks ---------------------------------------------------------------------- PPIG Discuss List ([EMAIL PROTECTED]) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
