ambiguities in the development process

Andre Garzia andre at
Tue Apr 28 12:19:45 EDT 2009

I am a single man team, I write my specs and when I meet them, I give myself

it's a self-pavlov thing but it works.

On Tue, Apr 28, 2009 at 12:57 PM, Mark Wieder <mwieder at>wrote:

> Kay-
> Tuesday, April 28, 2009, 12:37:12 AM, you wrote:
> > I would suggest that a small portion of the alpha/beta/post release
> > patch cycle is destined to discover the ambiguities that the creators
> > of the original extremely accurate tech specs never envisaged.
> ...with a change of topic...
> I worked on a system a dozen or so years ago where we spent roughly
> the first 60% of our development time (some 8 months or so) hammering
> out the requirements spec. The direct opposite of modern agile
> development techniques. But the result was that we got almost all the
> ambiguities out of the spec so that at the end of that process all
> three stakeholders (development, QA, and documentation) could build
> their deliverables from the same spec in parallel. With the tweaking
> of weekly bug meetings to discuss the few ambiguous issues that had
> managed to sneak through, we delivered an award-winning java app
> pretty much on time and pretty much on budget.
> --
> -Mark Wieder
>  mwieder at
> _______________________________________________
> use-revolution mailing list
> use-revolution at
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:

-- All We Do Is Code.

More information about the use-livecode mailing list