Yes, I meant differently. I left out the entire fact-finding and prototyping, assuming that everyone does it via whatever means they deem appropriate, and all are reasonably successful. That process is a separate discussion altogether.
I agree with your final paragraph completely. Meeting the spec is the foremost concern. However, you stated in your second paragragh that "FB may make it easy for your to backtrack and add Y and Z afterwards." I've never seen a project that didn't evolve and grow over time (excepting the ones that were stillborn). It doesn't matter how well you do the initial development, 6 months or a year down the road, things will need to change. If they don't, either no one uses the app, or the planners/architects/developers were friggin' omnicient. cheers, barneyb --- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com > -----Original Message----- > From: Shawn Grover [mailto:[EMAIL PROTECTED] > Sent: Friday, July 18, 2003 2:59 PM > To: CF-Talk > Subject: RE: Cons to Fusebox > > > -----Original Message----- > From: Barney Boisvert [mailto:[EMAIL PROTECTED] > Sent: Friday, July 18, 2003 3:21 PM > To: CF-Talk > Subject: RE: Cons to Fusebox > > >If I were to start a new project tomorrow, I could either grab > Fusebox (or > >Struts, or whatever) and start architecting and coding, or I could start > >building a framework, and refine it and test it, and then start > architecting > >and coding, once the framework is complete. Fusebox4 has been months in > >development; Struts 1.1 was much longer than that, and both have > both been > >years from the initial get-go to now. > > I'm going to take this statement at face value for a moment, even though I > suspect you mean differently. So, what I'm hearing is that your > client says > they want X, and you begin coding X immediately. But I do not see in you > statement where the requirements gathering and planning process has taken > place to determine if the client really wants X, or maybe X and Y and Z. > > If this is the case, then yes, FB may make it easy for you to > backtrack and > add Y and Z afterwards. But if you've done the requirements gathering > beforehand (I'll assume you normally do Barney - this is simply for > discussion puposes), then you would have planned for X Y and Z from the > start, before any code was written. In which case, FB still > doesn't really > buy you anything that simply following good practices would. > Yes, it makes > things easier in some ways, however, so does Object Oriented Programming, > and so does Struts, or any other methodology - even some home grown ones. > > As near as I can tell from this discussion, it comes down to a matter of > coding style. If you prefer the FB "style" of coding, then do it. If you > prefer a custom "style" of programming, then do it. There is no > "right" way > to do the code - other than making the application do what it's > supposed to. > > My thoughts, not yours... > > Shawn > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
