On 01/07/07, Brian Foster <blf at utvinternet.ie> wrote:
> | Date: Sun, 01 Jul 2007 18:02:43 +0100
> | From: Kae Verens <kae at verens.com>
> | Errors-To: ilug-bounces at linux.ie> |
> | Patrick O'Connor wrote:
> | > Thanks again Kae, I feel like an idiot for not testing it thoroughly
> | > before release. That is why I am in constant awe of good devs!! ;)
> | I think I wouldn't be alone in saying that it's not usually the
> | developer that notices the bugs! I have a habit of writing code,
> | testing only the bits I'm interested in, and publishing it.
> | Thank $deity for bug testers that are not coders!
>> good developers tend to have (learn) a number of
> habits. perhaps the most critical is to keep
> learning. in particular, to learn from mistakes
> (not only yer own, but those of others as well).
>> so, for instance in this case, if Patrick were
> to ever do another survey, I'd hope he'd recall
> this experience and (guessing here) try to check
> (more of) the various decision paths.
>> the Really Good developers do more than just
> learn. they (i) actively try to avoid mistakes;
> and (ii) actively try to ensure the (inevitable)
> mistakes are easy to identify, root-cause, fix,
> and (re-)test. these are all closely related.
>> generally, this mean carefully thinking through
> the design _and_ how to both test and debug the
> implementation (and, when possible, the design
> and/or model(s) itself).
>> that need not be complicated. (and, in fact, it
> should not be complicated, since, e.g., any debug
> code must also be debugged.) as one example, I'm
> a huge fan of "asserts" (esp. for languages that
> support the concept). a design/implementation
> with known entry/intermediate/exit conditions can
> translate into a highly useful, and natural, set
> of invariants (assertions). I find that putting
> effort into writing correct, not always trivial,
> assertions helps to check the code as I write,
> and flags up specific (additional) cases to be
> tested. plus, when a correct assert detonates,
> because (my) code is liberally sprinkled with 'em,
> the detected failure is often quite close to the
> coding error.
>> ( however, I'm not saying that that approach is
> necessarily viable in Patrick's current case. )
>> another part of this active process of problem
> avoidance is to realise it never stops; or, to
> put it another way, the tests et al. will have
> to be, for whatever reasons (plural), repeated
> more than once in the future.
>> what that translates into depends very much on
> just what it is you need to test. again using
> myself as an example, in my last job, this was
> "easy": I worked on a compiler, and compilers
> are very deterministic. so there was a large
> and ever-growing fully automated test suite.
> the suite tended to test the rare and corner
> cases, since (as Dr Knuth and others have
> observed), the usual cases tend to take care
> of themselves (and are often covered by the
> rare and corner case testing).
>> more relevant is the effort put into the test
> suite: the rule-of-thumb was it took at least
> as long to develop a suitable collection of
> tests as it did to develop (or fix) the feature
> being tested. e.g., if it took a day to twiddle
> the compiler, it'd take at least another day to
> build a comprehensively adequate set of tests.
> (this wasn't because the test suite was hard to
> extend — it was easy (by design!) to extend — but
> because non-trivial testing is, well, non-trivial.)
>> ( however, what repeating testing means in the
> case of GUIs, such as Patrick's survey, seems
> tricky? I'm not a GUI person, so I'm not too
> up on just what is possible or recommended. )
>> the upshot of learning from mistakes, designing
> out defects, designing in tests and debugability,
> and repeating testing is it can be "the coders"
> who find (most of) the problems.
>> nonetheless, testers, test suites, et al., who
> are not coders and developmental tests are still
> critical. but they are essentially a last resort
> (or at least used as one); broadly, if they (or
> the users/customers/clients) find a bug, it is
> a lot harder/slower/expensive to fix.
>> which is one reason Really Really Good developers
> try to "front load" the design and development.
> the sooner (and quicker) an issue is identified,
> the sooner, cheaper, and better it can be fixed
> (or, if found soon enough, essentially avoided).
>> ( there are many different ways of front loading;
> "rapid prototyping" is a popular technique ATM. )
>> then of course, in cases like Patrick's survey,
> there's the issue of designing a useful survey
> (and obtaining useful replies). this can be
> rather tricky! I note Patrick's survey is
> self-selecting (which can be Ok); this e-mailing
> list is perhaps a biased collection of potential
> respondents (which can be Ok); and (after quickly
> looking at it) did not see (1) any attempt to
> check what "open source" means (to the respondent);
> nor (2) any attempt to quantify this mysterious
> "open source" versus probable alternatives (e.g.,
> proprietary, internal, non-computerised, et al.).
Thanks for your words Brian. In relation to the potential for bias,
the survey is to try and gain an insight into the motivations of open
source / free software developers and users specifically, not computer
users in general.
The paper I am writing is focussing on two elements of open source /
1. The tools open source free software developers use to work in a
2. The motivations driving developers to create open source / free
software. Which the survey directly addresses.
As such, this survey is not really aimed at those who are ambivalent
towards what flavour of software they write / use etc. It also makes
the assumption that people responding to the survey know what the term
open source means. To keep everyone happy I suppose I should have used
the terms open source / free software ;)
Thanks again for taing the time to respond, I really appreciate all
>> apologies for rambling on. and on. and on!... ;-)
I tend to be prone to that myself.. LOL
> ▶ ▶ I AM CURRENTLY LOOKING FOR A JOB! ◀ ◀ | Brian Foster
> Experienced (>25 yrs) software engineer: | Montpellier, FRANCE
> • Unix, Linux, embedded, design-for-test; | Stop E$$o (ExxonMobile)!
> • Software/hardware co-design, debugging; | http:/www.stopesso.com
> • Kernels, drivers, filesystems, &tc; Résumé (CV) & contact details:
> • IDL, automated testing, process, &tc. http://www.blf.utvinternet.ie> --
> Irish Linux Users' Group mailing list
> About this list : http://mail.linux.ie/mailman/listinfo/ilug> Who we are : http://www.linux.ie/> Where we are : http://www.linux.ie/map/>
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!