On 8 October 2010 13:47, Marnen Laibow-Koser <[email protected]> wrote: > Colin Law wrote: >> On 8 October 2010 03:34, Marnen Laibow-Koser <[email protected]> >> wrote: >>> involved before thinking about the desired functionality. >>> I'll turn the question around: why would you want to consider >>> implementation before functionality? �What possible benefits could it >>> produce? >> >> Well of course you need some idea of functionality before anything can >> be designed. If I can bring back a quote from your earlier post: >> >>> ... when I >>> put together an application, I usually think first about how I want it >>> to present itself to the user and what the user should be able to >>> accomplish (and write Cucumber scenarios accordingly). Only as a result >>> of making those scenarios reality do I write model classes or anything >>> else. >> >> I am suggesting that there is a phase before considering in detail how >> the application should present itself to the user. > > There is the phase of deciding in very general terms what the broad goal > of the application is -- in your case, something like "people should be > able to order products from us". > >> For example to >> take the ubiquitous shopping app, before considering how the logon >> page should operate there is the decision that there will be users and >> that there should be a page where the user can logon. > > Sort of. Out of the idea that users can order products comes the idea > that we need a way to tell the system who's ordering. From that idea > may come the fact that we want user accounts and a login interface. > That's probably as far as I'd go down that particular path in initial > requirements gathering with my client. > >> Similarly >> before considering how precisely the user adds a product to his >> shopping cart there is the decision that there will be products and >> shopping carts. > > First step: Users should be able to order products. > Second step: We want to present them a shopping cart interface to do so. > Third step: Users should be able to do the following things from that > interface. > > The domain concepts emerge from requirements gathering. They are not > considered before it so much as simultaneously with it in my experience. > >> It is at this stage that initial stabs at what the >> models will be can be made (note that I am not suggesting writing any >> code here, merely thinking about what the models will be). > > No! It's premature. The business domain objects are a good start for > guessing what model classes you'll need, but it's absolutely wrong to be > thinking like a programmer when you're doing business analysis. > >> It does >> not seem feasible that one can write a Cucumber scenario for user >> logon and then go from that to the idea that maybe one needs a user >> model. > > I assure you, it is entirely feasible. I do it all the time: write a > Cucumber scenario with perhaps only the vaguest idea of what models I > need, then start experimenting with the best way to make it pass. > Remember, Cucumber scenarios are written in English for a reason: > they're meant to test user-facing behavior, not code. You could > completely rearchitect a system and still have the Cucumber scenarios > pass. > >> Is it not true that the concept of a User must exist before >> one can write the scenario? > > The business concept, sure. But it's premature to translate that into a > concept of a User class in the requirements gathering stage. > > (To be fair, user management is simple in most cases and requires a User > class. But I've been doing stuff with my medical records application > where I may have a bunch of features gleaned from the client and > translated to Cucumber stories -- and still have no idea what the > underlying models should look like.) > >> Note again that I am not suggesting >> writing any code at this time, just thinking about what the models >> should be. > > And I'm telling you that that's a bad idea. Don't think about models > till you actually need to write them.
I think we are just going to have to agree to differ on this one, though in fact I do not think our viewpoints are as far apart as it might appear from this discussion. I also think that you have to allow a bit of flexibility in approach for the different ways that different peoples brains work when analysing a system requirement. Looking back over my career I cannot remember any instances where I got in a mess or wasted significant time by thinking about the underlying objects too early in the analysis, but I can remember instances of problems when I left this phase too late. Of course the length of my career may have a bearing on what I can and cannot remember :) The one thing that I am sure we can agree on is the importance of making sure that what is provided is what the user wants, not what you think he aught to want or what his managers thinks he wants. Provided we achieve that then slight variations in the route to get there are not so important. Failing to understand the user requirements is the principle cause of IT system failures I think. Regards Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
