Re: [boost] Interest in a Behavior Driven Development Framework

From: Richard Newman (richard_at_[hidden])
Date: 2006-09-15 10:34:18

Rene Rivera wrote:
> 
> It's a very sad day when people can again think that customers can 
> program. After 25 years of programming this seems to be a recurring 
> false pattern. Having done a stint in knowledge based reasoning AI 
> development I can tell you that there's a very good reason for the term 
> "expert". And for those not familiar with some of the AI aspects in 
> this, unless you are willing to make non-programmers write in Esperanto, 
> you'll be faced with natural language parsing nightmares.
> 
This is probably off-topic, but I've struggled with this question, and 
would like to hear more on this.  If it should be in a different list, 
please help me to move the discussion there.

It's not so much that I would ever expect laypersons to be able to 
program. But I do expect the code to be written such that the layperson 
can get the gist, if not every detail, of what it is to be doing.

I have been recently working with the notion that as much as possible 
(and that's quite a bit), C++ objects, etc., should be in the terms of 
the problem domain: nothing too controversial there.  Even if I were 
working procedurally in C rather than in OO with C++, I would want my 
breakdown to make sense with regard to the domain it is responding to.

Further, and this is potentially the rub, the implementation should also 
be in those terms.  If we're talking about simpler programs such as 
examples in undergraduate CS courses, this is fairly obvious, but it's 
real value is in the more complex code, such as in commercial 
production.  So often code ends up overly complex and rife with 
potential error simply because it couldn't be read.  If you follow the 
principle that a layperson should be able to follow it, then you've 
probably thought enough about how you'd explain it that you've done a 
better job of organizing the code.  I've seen code written for academic 
purposes and much of it requires far more from the reader than should 
ever be necessary.

Even with C++ templates where the syntax can be very arcane, one might 
have to help read past that and I certainly would agree that a detailed, 
bit by bit analysis of the consequences of its code construction would 
likely be going too far. But again, a reader should be able to follow 
the general points of the algorithm and use this as a way to reconcile 
specification and expectation with actual code design.  In short, the 
closer the code is written in terms of the specification (whether 
formally or informally developed), the less likely the designer will 
miss the mark. The exceptions I allow to this principle generally occur 
in performance-critical code.

Finally, I'm not suggesting that code be written such that it matches 
the original explanation given by a layperson customer; frequently they 
haven't done sufficient analysis to recognize better design 
possibilities.  However, once a design is developed, the customer should 
be able to follow what it is as kind of an application of the Feynman 
freshman explanation principle (experts are only experts if they can 
explain the subject to a layperson).

So if you have a more rigourous way of determining where the line should 
be drawn or if my premise is not supportable, I would be all ears (or 
eyes as the case is here).

Kind regards,
Richard Newman
richard_at_[hidden]