It wouldn't hurt to join this discussion over at [EMAIL PROTECTED] > Here a list, there a list, everywhere a list.
LOL -Drew Harris On 6/13/02 12:38 PM, "Balazs Wellisch" <[EMAIL PROTECTED]> wrote: > Yup, that's been my biggest problem. How do you charge for an iterative > process? Almost none of my clients are willing to pay for and extended > discovery process which is precisely what needs to be done to build the > project right. So, I've been breaking up large projects into smaller more > manageable phases. > > First I spend a good month or so on requirements gathering, domain analysis, > and building an html prototype. I usually under charge for this phase > because it's often very hard to convince clients that this is even needed. > But, in most cases a much larger project than the client originally thought > emerges as an end result. > > Now, I create and prioritize a list of modules to be built in accordance > with what's most important to the client. I treat each of these as separate > projects. Each module has its own scope and price. The client is happy > because they don't have to pay tens of thousands of dollars up front even > though they usually end up paying more in the long run. I'm happy because > this seriously reduces "scope creep" and leads to a better product in the > end. So it works out pretty well. The only down side is that it takes a > little longer to see actual results than if I just started coding right > away. > > ...Do we need to take this over to the other list? Here a list, there a > list, everywhere a list. > > > > -----Original Message----- > From: Alan McCollough [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 13, 2002 7:54 AM > To: '[EMAIL PROTECTED]' > Subject: RE: Conversations #16 > > > 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 ==^================================================================
