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

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-09-15 11:22:01

Richard Newman wrote:
> 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).

But why would a layperson have to read pseudo-english embedded in
arcane C++ when she can read the documentation? IMO, (sorry Dean)
all this hoopla is just an elaborate excuse not to write proper
detailed documentation. IMO, programs that end up overly complex
and rife with potential error stems from the lack of documentation
and design discipline. Code goes haywire and get into a tangled
mess, and hence become unreadable in the process. It does not start
from unreadable code, it starts from lack of, inadequate, or
improper documentation.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net