Re: After 5 - radical idea: test first development

On 09/25/2014 02:28 PM, Sam Ruby wrote:
> On 09/16/2014 08:03 AM, Robin Berjon wrote:
>>
>> # We can change pretty much everything
>>
>> By this I mean: don't assume that the way things have worked in the
>> past is representative of how they have to work in the future. You
>> may have been told that some things can't be done that actually can
>> be. You may have encountered barriers that can be lifted.
>
> Just capturing some more ideas.  They may end up being dead ends, but as
> I've brought them up in other contexts (like telecons) I thought it
> would be worth capturing for this discussion.  At the moment, I have two
> points to make.  I'll put each separate idea into a separate email with
> a separate subject line.

This is the second of the series, the first can be found at [1].

One of the concepts of Software Development is that idea of Technical 
Debt[2], with a number of causes.  We've seen many of these during the 
development of HTML5.  An examples would be the "business pressure" to 
release HTML5 when one of the pillars on which it is based, namely a 
URL, is not at the same level of maturity.

Another is modularity, something Robin's proposal[3] touches on and has 
been discussed elsewhere[4].  I'll state that I see Anne's point in that 
if it is likely that an update to one document will need to be reflected 
in another that any modularity that comes in splitting a spec is 
illusory.  Robin's point is that this isn't always the case -- in fact 
taking Anne's own examples, it should be possible to add a new element 
to the HTML specification without needing to update XMLHttpRequest, 
despite the fact that there are two way dependencies.

But the point of this email is a different cause for Technical Debt[5], 
namely lack of test cases.  With specifications, this manifests itself 
in a number of ways: examples include the development of features that 
are later marked as at risk and are ultimately pulled, potentially 
invalidating prior reviews and requiring return to earlier phases of the 
process, and specs that fail to either advance to the CR phase or fail 
to exit the same.

Elsewhere, and at length, there has been a discussion of the need for 
living standards which often contain experimental and unproven items vs 
the needs for stable standards which limit themselves to items that are 
themselves stable and proven.

While as Robin has suggested "We can change pretty much everything", I 
suggest that we accept for purposes of this discussion that the W3C 
"brand" is intended more for stable and proven items.

A very effective strategy that a number of software products have 
adopted is Test First.  And the way this often works in practice is that 
people while people can work on branches/forks as much as they like, 
pull requests will not be accepted unless the necessary test cases are 
known to be present.

I don't understand why such an approach couldn't work here.

I've been told[6] that some may consider this hostile, but I would like 
to push back on this idea, and invite anybody who sees this differently 
to explain why this is a problem.

- Sam Ruby

[1] http://lists.w3.org/Archives/Public/public-html/2014Sep/0073.html

[2] http://en.wikipedia.org/wiki/Technical_debt

[3] http://darobin.github.io/after5/

[4] http://lists.w3.org/Archives/Public/www-archive/2014Sep/0004.html

[5] http://www.extremeprogramming.org/rules/testfirst.html

[6] http://www.w3.org/2014/09/25-html-wg-minutes.html#item03

Received on Thursday, 25 September 2014 18:58:32 UTC