On Sun, Oct 17, 2010 at 6:39 AM, Dr. David Kirkby <david.kir...@onetel.net> wrote: > On 10/16/10 01:21 PM, Burcin Erocal wrote: >> >> Hi, >> >> Motivated by the call for the bug days, here is an idea to manage the >> rapidly increasing number of "new" tickets on trac. > > It is well known in industry that the cost to fix bugs increases rapidly as > they time to fix them is delayed. See for example > > > http://on-agile.blogspot.com/2006/12/hidden-cost-of-delaying-bug-fixes.html > > It depends very much on the industry, but set of quoted values are: > > > $10 in Design phase > $100 in working code > $1,000 in released software > > Of course, in open-source software cost can not be considered too much in > monetary terms (though clearly in this case a company are willing to pay to > have bugs fixed). > > But if someone writes code with a bug, a second peson builds upon that buggy > code with their own code, it should be obvious that there is a lot to be > gained by fixing the bugs as soon as possible. But should not be allowed to > linger on for a long time. > > I feel we should be putting higher priority on fixing the bugs sooner, and > not adding more features. > > I recently wrote a very small shell script to automatically find bugs in > Sage. It was slow, as each test invoked Sage once. I should be able to speed > that up by a couple of orders of magnitude, by not starting a new instance > of Sage before each test. (I'm in the process of re-writing it in C). > > I can't help but feel that some of these could be caught much earlier, with > a bit more consideration given to testing. Simply by trying your code with > invalid input will often show bugs. > > sage: seed(1,2) > sage: seed(100,34) > sage: seed(1,2,3,4,5,6,7) > > will all crash Sage with an "Unhandled SIGSEGV". Plenty more sets of invalid > input to other commands will hang Sage, so the only answer is to kill the > process.
Though in an ideal world, this kind of thing wouldn't crash Sage, I'm more worried about the kinds of bugs where valid input causes a segfault, or, much worse, an incorrect answer. > I think the main problem is ignorance. Good software engineering techniques > do not form part of mathematics degrees, so most Sage developers are totally > ignorant of the issues. Then those motivated to find more information soon > hit the fact that books on this topic are not cheap. I have an 18-year old > copy of this book, which despite the complaints the 7th edition is out of > date, I think much of the material would be useful to Sage developers. > > http://www.amazon.com/Software-Engineering-Practitioners-Approach-International/dp/0071267824/ref=sr_1_1?ie=UTF8&s=books&qid=1287322048&sr=1-1 > > There's also plenty of books on software testing. > > http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Dstripbooks&field-keywords=software+testing&x=0&y=0 > > > Perhaps when William assembles the team in Seattle, he could find the money > to buy each person a book on software testing. Buy each person a different > book, then hopefully Sage developers will able to independently review the > material. Perhaps they each write a Wiki page on what they though was the > most important things they learned from the book. I would submit that practicing good software engineering techniques is more than a matter of finding the money (and especially time) to read a good book on it--we all have different priorities on what we can afford to spend "10,000 hours" on. (Note, I'm not saying it wouldn't be useful for all of us to learn these things, just that I don't expect working mathematicians to all find enough time on the side to become expert software developers as well). On a more practical note, I think it may help things if we actually used the priority field. Certainly Blocker: 14 Critical: 68 Major: 1609 Minor: 516 Trivial: 26 Is not the correct distribution. We have an extremely large number of components of varying scope as well, this could probably use some unification and cleanup as well. In terms of bug-fix-only releases, I don't think anyone would object to someone volunteering to do one (as long as the process didn't drag out longer than a normal release). - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
