Karen Lanrap wrote:
> rm wrote:
> 
>> Do you know *1* project where no backtracking was ever needed? 
> 
> Several. They died immediately on first try to backtrack.

Sounds more like they needed to backtrack, but were for whatever reason unable to do so without the project dying.
Not being able to backtrack is quite different from not *needing* to backtrack. :)

Frits van Bommel wrote:

> Not being able to backtrack is quite different from not *needing* to backtrack. :)

In a culture, where backtracking leads to immediate death, nobody _needs_ to backtrack ;-)

Karen Lanrap wrote:
> Walter Bright wrote:
> 
>> Design/code/design/code... iteratively is the real process.
>> There's a good reason for that - too often when implementing a
>> design we discover that the design won't work or could at least
>> be improved. 
> 
> Who is 'we' in this case?

Just about every software project outside of avionics software.

> Following your statement a very tiny set of coworkers might avoid desaster.
> 
> But your habits of evolving the D programming language make it hard to believe that under such management principles a project of about 1000 man years would come to success.

The only computer language I know of that was design then build was Ada. And that was a massive failure - Ada was not accepted until the design evolved quite a bit from that first mil spec.

Karen Lanrap wrote:
> Now one of your 490 coders comes to you saying: "I am unable to implement this because of erroneous design."
> 
> Are you willing to "sell" this detection to your management, your sponsor or your loan officer?

Yes, because you have two alternatives:

1) Fix the design, and take the $6,000,000 lump.

2) Ignore the problem, hope it goes away, and in the end have to write off the whole $147,000,000.

As Exhibit A of approach (2), may I suggest the Denver airport baggage handling system. I've also read now an then in the paper about other government software projects, like one for the FBI, that cost in the hundreds of millions of dollars, and needed to be scrapped completely because of flawed design.

Frits van Bommel wrote:
> Sounds more like they needed to backtrack, but were for whatever reason unable to do so without the project dying.
> Not being able to backtrack is quite different from not *needing* to backtrack. :)

That's true. A sensible approach will build in the ability to backtrack. It's like when a contractor buys stone for the tile job. He always buys a few extra to account for breakage and mistakes. Nothing worse than winding up a couple broken tiles short on a big job, and it not being possible to get more matching stone of just that color!

Walter Bright wrote:

> A sensible approach will build in the ability to backtrack.

Uhh, I see now, that there was a misunderstanding. It is the responsibility of every project leader to reserve cost and time buffers. She/he might use them for any purpose and even call that usage backtracking. But that is not the backtracking I was talking of.

I was talking about backtracking in the sense of requiring a bigger budget or more time than agreed on.

If a project leader plans buffers that are too large, the project will be taken by another leader or it dies. If the buffers are too tiny the leader failed---no backtracking possible.

But because the leader of the coding is not in the duty for the design there will be a vital interest to discover erroneous designs early.

Walter Bright wrote:


> 1) Fix the design, and take the $6,000,000 lump.

$6,000,000 per month for an unknown time. If the buyer is willing to take that one will be lucky. Otherwise:

  3) the project dies.

> 2) Ignore the problem, hope it goes away, and in the end have to write off the whole $147,000,000.

The is surely the worst alternative.

Walter Bright wrote:
> Georg Wrede wrote:
> 
>> Kristian wrote:
>>
>>> So maybe we should have contents on APIs first. When we got the base  structure right, we can make competitions on parts (e.g. functions,  classes) that should be efficient, or hard to implement. Bulk (trivial)  stuff can be implemented outside the competitions later. Also, API  implementations should include documentation.
>>
>>
>> I think an API competition should definitely be in two stages:
>>
>>  - compete on the most useful and best spec
>>  - then compete on the most elegant implementations of the winning spec
> 
> 
> Design, then code, is the development approach that everyone advocates. It's also the approach nobody uses <g>. Design/code/design/code... iteratively is the real process. There's a good reason for that - too often when implementing a design we discover that the design won't work or could at least be improved.

True!

However,

If we had a separate contest on the API spec, then people really would "restrict" their thought to the API itself. Such restriction is never possible in an environment where the Task is to spec-and-execute some API.

As an example of the diametrically opposite situation, we might have a code shop where the boss tells Niles-the-Programmer to create an API and implement it. Now, knowing from the outset that he's the one who has to actually implement whatever API he comes up with, will feed-back and personal beliefs on the relative required effort, hamper his judgement on the what-to-dos and what-to-not-dos?

In other words, hard-to-code things get reduced priority, hard-to-conceptualize things get lowered priority, and labourious APIs get less attention and respect.

An environment where the decision on APIs is disentangled from the decision on how to implement such, is much more fruitful for the end result than the former.

A contest where these two stages are separate, may eicourage quality due to the fact that participants in the API part may not have an intention of actually coding the API parts in then next competition.

Karen Lanrap wrote:
> 
> I was talking about backtracking in the sense of requiring a bigger budget or more time than agreed on.
> 
> If a project leader plans buffers that are too large, the project will be taken by another leader or it dies. If the buffers are too tiny the leader failed---no backtracking possible.
> 

like in every business, taking margins too small will lead to a loss on
the job, and when persistent to failure of the business,
otoh, talking margins too large will lead too no business at all.

roel

Sean Kelly wrote:
> Bruno Medeiros wrote:
>> Sean Kelly wrote:
>>> Lionello Lunesu wrote:
>>>> "Walter Bright" <newshound@digitalmars.com> wrote in message news:eh0hgs$q8h$1@digitaldaemon.com...
>>>>
>>>>> I'm happy to merge things in, but am reluctant to do so without reviewing the diffs line by line.
>>>>
>>>> That's what we have now. I think it's time for you to let go of Phobos. 
>>>
>>> It's a bit more complicated than that, since Phobos includes a bunch of compiler runtime code used by DMD.  This is also why GDC has a separate GPhobos where the only substantive difference is this runtime code.
>>>
>>>> There can't be a community lead standard library from which you take patches to include into DMD's distribution.
>>>
>>> Sure there can.
>>>
>>>  > We'd end up with another Ares.
>>>
>>> I think Ares isn't used widely for two (or perhaps three) reasons:
>>>
>>> * Visibility
>>> * Features
>>> * Endorsement (maybe)
>>>
>>
>> Speaking of Ares, there is something I've wanted to have clarified, which is apropos to this discussion:
>> My issue with Ares, is actually one of objective/purpose. The goal of Ares is stated to be an alternative to Phobos, but my question is how much of an alternative?
>> Is it meant as a general, encompassing alternative to Phobos, targeted to the general (D) programmer populace, or is it a specific alternative, where it aims to deal with some issues you (and some more coders) have with Phobos, but not go further than that? Because a standard lib is a wide and ranged collection of code, and all modules and aspects of it need to be well-considered.
> 
> It's original aim was to be a complete replacement, but a lack of community participation changed the focus a bit.  Ares is now really just a minimal framework on top of which a standard library may be built.  And progress there has stalled a bit in the past few months because I've been too busy with other things.  However, I do have some redesign ideas in mind that should hopefully bear fruit before too terribly long.  And these are intended both to address deficiencies in the original design and to hopefully make for the beginnings of a better library.
> 
> 
> Sean

That's good to hear. For an example of what I meant in the previous post, here's two things I think should be in the standard library, and for what I see they are not in Ares (as well as Phobos):
* the write/writeln unformating output functions.
(news://news.digitalmars.com:119/eg2aka$1ot9$1@digitaldaemon.com)
* extended path&file management functions, like Kramer's pathext:
http://www.digitalmars.com/d/archives/digitalmars/D/announce/4363.html


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D