For the Love of Pete! How many lists will I have to keep up with...? I guess it's not a bad idea though... ;-)
-Drew Harris -----Original Message----- From: hal helms [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 12, 2002 11:08 PM To: [EMAIL PROTECTED] Subject: RE: Conversations #16 Folks, I've just created a [EMAIL PROTECTED] discussion group. (Thanks to Patrick McElhaney for his excellent suggestion.) Shall we inaugurate the group by continuing this interesting discussion over there? To subscribe, send an email to [EMAIL PROTECTED] Once you're subscribed, send messages to [EMAIL PROTECTED] (this isn't case-sensitive, btw). Hal -----Original Message----- From: Balazs Wellisch [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 12, 2002 11: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 ==^================================================================
