Indeed. My experience has been that the client does not have it together in figuring out what they have. Hence why we as CFers enter the picture. They got a problem, and we are to devise the solution. As you chat with the client, you start to find out that they know somewhat what they want, and they know somewhat what they got now, and the two aren't even close. So as you start to formulate what the solution is, they start to glom additional "It should have this, too" stuff on there. It starts to take shape. Front end. Database. Scope Creep. Forget that last one, that never happens. But I've found the birth of an application to be an, whats a fancy word, iterative process. Yeah. Iterative. And after maybe a dozen of those iterations, everybody feels good about it and it might be time to start grinding out some code. Maybe.
> -----Original Message----- > From: Balazs Wellisch [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, June 12, 2002 7:43 PM > To: [EMAIL PROTECTED] > Subject: RE: Conversations #16 > > I must be a dummy or something, but the domain analysis usually takes me a > lot longer then a couple of hours. It's more like a day or two and more > often than not it takes several meetings between the client and myself. > > Actually, the real reason for this is that a lot of times the clients > themselves don't have a clear idea of how they're doing things. At least > this has been my experience... > > Balazs > > > > -----Original Message----- > From: BORKMAN Lee [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 12, 2002 7:24 PM > To: '[EMAIL PROTECTED]' > Subject: RE: Conversations #16 > > > I find that I cannot do any kind of wireframe or prototype until the > client > and I have done at least a basic domain analysis. In other words, I need > to > know what the business-level "things" are that the application is intended > to deal with, and I need to know how they relate to each other. Until > this > happens, then I am likely to waste substantial time thinking that a > "Master > Report" is a particular kind of beast (you know, a "report"), when it's > actually a completely different kind of animal (a work authorisation). > > The domain analysis I use is essentially an entity-relationship diagram > with > only a few important attributes included. It's really just named boxes > with > one-to-one, one-to-many, many-to-many connections drawn. I think of it as > a > rich kind of glossary, so that the client and I can each understand what > the > other is talking about. This is what *I* mean by "commensurability", ie, > our terms match up, and our conversations are useful rather than > frustrating. > > This analysis is unlikely to take more than a couple of hours, and is > certainly not anything like a complete data design, but until I have at > least this kind of information, I don't think that I can help the client > at > all, because I can't *understand* what we are doing or why - I can only > make > wireframe or prototype changes at the client's request, while thinking > "okay, I don't know why the hell you'd want to have that page right there, > but you're the client, and you obviously know what you're doing." > > Inevitably this domain analysis evolves as the wireframing and prototyping > proceeds, but by the time the Fusebox architecting is ready to proceed, I > have the substantial makings of the data design ready to go too. > > I guess I'm an old-fashioned kind of guy... > > LeeBB > > > > > -----Original Message----- > From: Hal Helms' Occasional Newsletter [mailto:[EMAIL PROTECTED]] > > > Conversations > Informal talks on software development with Hal Helms and Steve Nelson > Topic: When Do You Design the Database? > Steve Nelson: Well, we're back in business. > Hal Helms: Yep. Last week, we talked about various community resources. > Steve Nelson: One guy wrote me an email saying he thought the topic was > "too > controversial". > Hal Helms: Community resources controversial? > Steve Nelson: Hey, I just read the email. > Hal Helms: Wow, he should hear some of the ideas we reject! > Steve Nelson: So, what was your most controversial idea? > Hal Helms: About development? > Steve Nelson: Yeah. > Hal Helms: I suppose it would be the one where I suggested that corporate > accountants be chained to the damned cubicles they're so fond of. Not > forever, you know, but maybe for a year. > Steve Nelson: Chained there, huh? > Hal Helms: Right. I mean, since they're so productive a work environment > and > all and so people friendly, let's let them stay there for a while. Their > families could come and visit them on weekends. They could try to do > intellectual work with more noise than a train station at rush hour. I > think > it might be...enlightening. > Steve Nelson: And that was controversial? > Hal Helms: Well-it was among accountants. > Steve Nelson: How about other controversial ideas? > Hal Helms: Well, I have one that-when I say it-people look at me like it's > the oddest thing I've ever said. > Steve Nelson: Gee, they must not know about the accountant-cubicle idea. > Hal Helms: Right. > Steve Nelson: So, what is it? > Hal Helms: I tell people: when you're building a new application, design > the > database last. > Steve Nelson: Well, it certainly does fly in the face of conventional > wisdom. > Hal Helms: But you do that, right? > Steve Nelson: Absolutely. Now, sometimes, I can't - the database is > already > built, but when possible, I do it after all the architecture is done. > Hal Helms: Sounds controversial, all right. Why wait until the last to > design it? > Steve Nelson: What happens on a typical project? We have some requirements > documents, some graphical comps and then-bam! Start on the database! > Hal Helms: Yes, that's pretty much right. > Steve Nelson: So, you've got the coding folks waiting on the database to > be > built. And then, you have to populate it with some data so your queries > work. All this time, the programmers are waiting. Lots of pressure to "get > the DB done!" And so, it does "get done", but usually, that pressure > yields > a design that isn't thought through completely and so the database ends up > changing while coding is going on. > Hal Helms: The worst of all possible worlds. > Steve Nelson: Brought about by the best of motives: Let's get coding! > Hal Helms: Or, the flip side of that is that enough time is given to the > database design and then the coders start running out of time. Bad stuff. > Steve Nelson: So, what do you recommend people do? > Hal Helms: I think that until you have identified the people and things > that > are going to populate the model world you're building-and that's > essentially > what writing software is-creating a model world. > Steve Nelson: Right. > Hal Helms: Until you know what the inhabitants and furniture and stuff of > that model world are going to be, you're not ready for a database. Once > you > have determined that- > Steve Nelson: Something that you do by architecting the application. > Hal Helms: Yes, once that's done, only then are you in a position to ask > the > much more mundane question, "How shall we store all this stuff?" And > that's > really all databases are there for: to store stuff. > Steve Nelson: That doesn't sound very...sophisticated: databases are there > to "store stuff". > Hal Helms: Hmm...good point. How's this? Databases are there to make > objects > persistent. > Steve Nelson: Ah, much better. And it means the same thing. > Hal Helms: Seriously, though, the point is that what's important are the > things being stored and NOT the boxes we store those things in. Relational > databases sometimes obscure this point because they do require a high > degree > of sophistication to properly store things. > Steve Nelson: I sometimes tell clients when they get hung up with > technical > details, "Imagine that we have magical technology that lets us do whatever > we want to do, just by wishing it into being. Now, the REAL question > remains, What do we want to do?" > Hal Helms: That's really good. The problems we run into aren't usually > ones > of "we know exactly what we want to do, but can't figure out how to > implement it". It's much more common that we haven't really thought > through > our scale model world to make sure that everything is coherent. Or-here's > a > sophisticated word-commensurable. I learned that one in philosophy class. > Steve Nelson: Nice word! It means? > Hal Helms: Just means that everything fits together and there are no > logical > inconsistencies. So what we're both saying is that doing the database last > makes sense because it gives us time to discover the things that make up > our > model before trying to determine how to store those things. > Steve Nelson: Yes. And if you think about it, it also helps out the > project > schedule, because the database design can be done while coding is > beginning. > It takes the database design off the "critical path", in project > management > lingo. > Hal Helms: Ah, but what are the coders going to use to test out their > pages > that require record sets returned by queries? > Steve Nelson: I think some guy wrote a custom tag to help out with that. > QuerySim.cfm, if I remember correctly. > Hal Helms: Why, that's mi-[must...control...ego]-I mean, why don't you > explain how to use that, Steve? > Steve Nelson: Why, I'd be delighted to. It works as a tag pair. The first > line indicates-well, why don't you look at this and see if it makes sense. > <cf_QuerySim> > CoolGuys > firstName,lastName > Steve|Nelson > Hal|Helms > </cf_QuerySim> > Hal Helms: So, "CoolGuys" is the name of the record set to be returned. > Steve Nelson: Yep. And the record set has two fields or columns: firstName > and lastName > Hal Helms: And then this particular QuerySim returns two rows of data. > Steve Nelson: You got it. Cool, huh? > Hal Helms: Say, Steve, you don't happen to know who-you know-WROTE that > tag, > do you? > Steve Nelson: I don't remember exactly, but I do remember that Bert Dawson > took the original code-which was apparently pretty bad-and made it lots > easier to use. Can you believe it? The original author made it so you had > to > use a separate .ini style file for the recordset contents! Good thing Bert > fixed that! > Hal Helms: Doh! > Steve Nelson: What's that? > Hal Helms: Oh...nothing. Well, what if you don't want any rows of data > returned? > Steve Nelson: You just omit the data lines altogether. > Hal Helms: And if you want certain fields left blank? You can't just have > pipe symbols next to each other and expect CF to know those represent > empty > elements in a pipe-delimited string. I mean, it won't work. > Steve Nelson: You can just use the word "null" in there and the tag will > replace that with an empty string. > Hal Helms: Gee, that's some clever programming, wouldn't you agree, Steve? > Steve Nelson: I'm telling you-that Bert Dawson is a clever guy. Hey, > what's > the matter? It sounds like you're choking or something. > Hal Helms: Oh, don't worry about ME! I'll be all right. > Steve Nelson: Oh, OK. Good. > Hal Helms: So, is that it for today? We both agree on the efficacy of > doing > the database design last. > Steve Nelson: Yes, I'd tell people to whom this sounds like heresy to try > it > out on a little project. I thought it was weird at first, too, but there's > nothing so convincing as success. So, yeah, I guess we're done. Good > thing, > too, as we're running out of room. You have anything else? > Hal Helms: Just a little thing. A question, really, is all. In the example > record set you gave-CoolGuys-you had Steve Nelson first and THEN Hal > Helms. > I know it seems silly, but that might imply to certain readers that-and > again, I know this is silly-but it might sound like you're saying that you > are cooler than I am! > Steve Nelson: No, that's not silly at all. It's absolutely true. In the > coolness scale, I'm way ahead of you, my friend. That's what we call a > "universal truth"-a little phrase I picked up in philosophy class. > Hal Helms: Well, if you're going to be like that, then I have to tell > everyone that the AUTHOR of the QuerySim tag- > Steve Nelson: Sorry, buddy, but we're out of space. Gotta run. See you all > next week. Man, you sure you're OK? You gotta do something about that > choking noise you're making... > Steve Nelson runs SecretAgents.com, a site for putting together clients > and > developers. If you need consulting or help on project management, you can > reach Steve at [EMAIL PROTECTED] > > Hal Helms provides training on Fusebox and FLiP, and writes and speaks on > software development methodology and architecture. His site is > www.halhelms.com. You can reach him at [EMAIL PROTECTED] > To unsubscribe/change profile: click here > To subscribe: click here > > > Email list management powered by http://MailerMailer.com > > > IMPORTANT NOTICE: > This e-mail and any attachment to it is intended only to be read or used > by > the named addressee. It is confidential and may contain legally > privileged > information. No confidentiality or privilege is waived or lost by any > mistaken transmission to you. If you receive this e-mail in error, please > immediately delete it from your system and notify the sender. You must > not > disclose, copy or use any part of this e-mail if you are not the intended > recipient. The RTA is not responsible for any unauthorised alterations to > this e-mail or attachment to it. > > > ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
