>>>>> "O" == Ovid <[EMAIL PROTECTED]> writes:
O> --- Uri Guttman <[EMAIL PROTECTED]> wrote: >> when this gets to something close to coherent, i will start on >> coding it. O> With all due respect, that's a huge mistake. There are times that BDUF O> (Big Design Up Front) is useful, but over and over again I see that O> people try BDUF and then discover that they've designed themselves into O> a corner and the code has to go through ugly contortions to fit the API O> when what you want is an API that naturally reflects the actual use of O> the code. in some cases i would agree but the design IS the problem here and the coding will actually be fairly easy. as i mentioned i have already developed (and fully tested) a similar module with a stem specific api so i will be using as much of that work as i can. and that module was the 3rd implementation so i already went through the process you stated. :) the two earlier versions didn't have any major design up front and were done to solve the same async/wait flow problem. and they stunk since i didn't support enough feature due to lack of up front design. both had to be totally scrapped for later versions as i learned what is needed in the module. true, i coded those two versions very quickly and the third (current) one took much longer (due to writing a flow compiler with Parse::RecDescent and an interpreter and many tests) but i did work on the api before i coded it. O> Just start testing and writing the thing and let the design emerge from O> the code and the refactoring. I've been astonished at how much easier O> to get things *right* by doing this. By testing first and letting the O> design be driven by actually using the code as you're going along, it's O> much easier to spot design flaws. i agree in general but my mind is on finishing (not polishing) the pod/spec. note that i said 'coherent' and the current draft is not near that IMO. i expect to make changes and such but it is over 90% done in my head and maybe 50% done in text. i will probably start coding soonish anyway. O> Of course, the other potential flaw that I see in your reasoning is one O> can plan for years and never have to write the code. Not that you O> would ever do that ... :) heh. with stem i spent 3 months working on the concepts and designs in my head with not one written note. it took 1 month for the initial web pages which was as much a spec as anything else and then 3 months coding (with few proper tests which i regret) to get version .01 running. but that was how i needed to work on that as it had to be the right architecture to suit me. so i will get coding on this soon enough but i will get the pod/spec into reasonable shape (flesh out the missing sections, be coherent) and such. i have so much of the coding design done in my head and it isn't that complex so that when coding starts (remember, i will cut/paste/edit the most complex part which is the flow compiler/interpreter and lots of tests) it will get done fairly quickly. i have been working on the coding design in my head and been discussing some things with damian and that helped both the api and coding. much of the coding is clear and done in my head. also i plan on offering a talk on this to oscon so i do have deadlines to get the coding done. that helps! :) other than that, any other api feedback? thanx, uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
