[ILUG] Open Source Developers and Users Survey

[Brian Foster]

  | 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.).

 apologies for rambling on.  and on.  and on!...  ;-)
cheers!
	-blf-
-- 
▶ ▶  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