<html><P>The correct link (I promise, we are getting rid of the frames soon!!) to the Test Driven Development thesis is</P>
<P> <A href="http://www.erlang-consulting.com/thesis/test_driven_erlang.html">http://www.erlang-consulting.com/thesis/test_driven_erlang.html</A></P>
<P>TDD proved to be the best approach.<BR><BR>Francesco<BR>--<BR><A href="http://www.erlang-consulting.com">http://www.erlang-consulting.com</A></P>
<P><BR>>-----Original Message-----<BR>>From: Martin Carlson [mailto:martin@erlang-consulting.com]<BR>>Sent: Thursday, January 26, 2006 12:14 PM<BR>>To: erlang-questions@erlang.org<BR>>Subject: Re: Software life cycle in Erlang<BR>><BR>><BR>>I would say it hate to do with the preconditions, is there a spec (the <BR>>optimistic approach..)? in that case what kind of spec you got, what <BR>>are the requirements, are there any high risk requirements and so on.<BR>>In any case an iterative model is proven to be very flexible <BR>>productive. Have a look at Fowlers page, lots of info.<BR>><BR>>Some pointers though:<BR>><BR>>Scrum: http://www.controlchaos.com<BR>>TTD: http://www.erlang-consulting.com/about_fs.html<BR>>General agile stuff: http://www.martinfowler.com<BR>><BR>>----------------------------------------------<BR>>Martin Carlson<BR>>http://www.erlang-consulting.com<BR>><BR>>On Jan 25, 2006, at 3:19 PM, Thomas Lindgren wrote:<BR>><BR>>><BR>>><BR>>> --- "Eduardo Figoli (INS)" <eduardo@inswitch.us><BR>>> wrote:<BR>>>> I'm trying to figure out the best model for software<BR>>>> development in Erlang.<BR>>><BR>>> The best _model_ seems to be iterative development of<BR>>> some sort, perhaps test driven. AXD 301 had great<BR>>> success with steadily improving "increments", to take<BR>>> one of the great success stories.<BR>>><BR>>> Taking a number like 35% for implementation means your<BR>>> whole project is done about 50% faster (in 2/3 the<BR>>> time) even if the language permits infinitely faster<BR>>> development than the state of the art, simply because<BR>>> the rest of the phases aren't concerned with<BR>>> programming. (That's the usual argument against<BR>>> switching programming languages, of course.) This<BR>>> doesn't seem right -- the added flexibility also means<BR>>> you can use powerful new development processes.<BR>>><BR>>> My recommendation: try to "switch to better rules".<BR>>><BR>>> Best,<BR>>> Thomas<BR>>><BR>>><BR>>> __________________________________________________<BR>>> Do You Yahoo!?<BR>>> Tired of spam? Yahoo! Mail has the best spam protection around<BR>>> http://mail.yahoo.com<BR>><BR>></P></html>