On 10/19/10 05:06 PM, kcrisman wrote:
I was not suggesting anyone spend 10,000 hours studying the subject of
software engeering. I'm not suggesting people need to be experts. But
perhaps spending 20-50 hours on it is not unreasonable. I don't know
about you, but I've probably devoted 1000 hours to working on Sage, so
20-50 is a small percentage. I think 20-50 hours would be for you
too.
It's not clear to me that without a specific time and place to do so,
that it would be particularly effective to spend 20-50 hours reading
books about this.
I don't have much experience to say whether you are right or wrong. I do *not*
have a software background. I have never done any sort of computer science degree.
However, I had had to write code which others will use, and it became clear to
me that on a large project one needs to do a bit more than just writing the
code. Based on my experience, I feel that 20-50 hours reading about what are
good software engineering practices would be useful. Those are just as relevant
if you code in C, assembler, Python or foobar.
Software seems to be one of those things that is
hard to really learn how to do without actually doing it.
My main point was not about the code one writes.
Clearly if you write in Python you should know about Python, but that's another
matter altogether. I tend to agree that one of of the best ways to learn a
language, is to use it.
Things that I believe would be good for Sage, and one could get some useful
understanding in 20-50 hours from a software engineering book would be:
* An understanding of how software projects should be managed. This is
especially so for William of course, but in general I think that's useful to
know for all of us. To a certain extent, some trac tickets have to be "managed".
* An understanding of why bugs should be fixed as early as possible.
* Understanding the different sorts of tests that software developers use -
black box testing, white box testing etc.
* Automated testing tools.
* Understanding ways to estimate the quality of code. At the moment there is no
analysis of defect rates in Sage.
* The life-cycle of software. Analysis -> Design -> Code -> Test -> Maintenence.
This applies to Sage as a whole, but also to individual parts of Sage.
* An understanding of why software wears out. What can we do to reduce the rate
of wearout?
10-20
hours spent trying to do some Sage development, but with a couple
quality software engineers looking over your shoulder the whole time,
might do it.
That's an entirely different thing - I'm not talking about that. Any course on
software engineering is not likely to have you writing code with someone looking
over your shoulder.
The idea of having one piece of a Sage days devoted to
people sharing ideas from books they read in a coordinated way sounds
plausible as well, though probably it would really depend on the Sage
days in question.
That would sound good. If each person read a chapter of a book on a topic, and
gave a short talk to everyone else, it should at least make people aware of the
other issues.
I bought this book
http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/0137035152/ref=sr_1_1?ie=UTF8&qid=1287529714&sr=8-1
though I'm not over-impressed with it.
Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of this
book
http://www.amazon.com/Software-Engineering-Practitioners-Roger-Pressman/dp/0073375977/ref=sr_1_4?ie=UTF8&qid=1287529714&sr=8-4
to be very useful.
You can pick up a used copy of the 6th edition (2004) for less than $2 on
Amazon.
To be sure, this is a design decision of sorts, and one at odds with
your books, perhaps. But unless we also can operate under the
implicit assumptions of them (which probably include things like
actual employers, or perhaps a pool of developers who all have similar
skill sets - neither of which is the case here, in a project which is
monstrously diverse in terms of skill needs and obviously very non-
hierarchical), I don't see how it's feasible to implement your ideas
on this, other than the reminders of good practice you give in public
fora such as this and on Trac tickets. Which I think that is having a
positive impact, incidentally!
:)
- kcrisman
The fact people have different skill sets, the fact we are not employed, the
fact there is essentially non-hierarchical, does not really change things too
much. Some aspects obviously do, as you can't demand people do what you want
when you don't pay them. But hopefully people more people would do things better
if they were aware of good practices.
Dave
--
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
