what is the fair market price for creating databases?
In the database topic area this question was posted:
what is the fair market price for creating databases?
And rather "fast" closed. It would be nice to get some Access experts opinions about this. How do you calculate a price, but also why that way and not .....
Nico
what is the fair market price for creating databases?
And rather "fast" closed. It would be nice to get some Access experts opinions about this. How do you calculate a price, but also why that way and not .....
Nico
ASKER
Nice, secure thought for you Brian, but...... the customer ?
When I buy a house (as a customer), I wouldn't like that at all. I need a fixed price for the mortgage !
Nico
When I buy a house (as a customer), I wouldn't like that at all. I need a fixed price for the mortgage !
Nico
This is a thing to be worked out between the customer and the consultant, for sure.
But houses do not go through an iterative development process. What you will wind up with is _very_ well established before the bank will make the loan.
The two just aren't the same. It is more like a lawyer/client arrangement. If that task is really well defined, the price is usually set. otherwise the fee is hourly, (or sometimes outcome-dependent).
Consultants are really in a position to say, "if you don't like the arrangement, you can just write the app yourself." (Not in a snotty way... But the market has much more demand than supply at the moment.)
I am consulting (home-based), with someone I met here, at 30/hr, and he is absolutely delighted.
I also moonlight at a company (on-site) that I used to work at for the low 20's per hour. That is largely as a favor. The employer took a chance on me when I really, really need that. I am glad to help back for cheap.
Brian
But houses do not go through an iterative development process. What you will wind up with is _very_ well established before the bank will make the loan.
The two just aren't the same. It is more like a lawyer/client arrangement. If that task is really well defined, the price is usually set. otherwise the fee is hourly, (or sometimes outcome-dependent).
Consultants are really in a position to say, "if you don't like the arrangement, you can just write the app yourself." (Not in a snotty way... But the market has much more demand than supply at the moment.)
I am consulting (home-based), with someone I met here, at 30/hr, and he is absolutely delighted.
I also moonlight at a company (on-site) that I used to work at for the low 20's per hour. That is largely as a favor. The employer took a chance on me when I really, really need that. I am glad to help back for cheap.
Brian
Rules to play by:
1. Don't take the project if don't understand the scope.
2. Charge a rate that is agreeable. The hourly scheme is the best choice as has been mentioned above.
3. In our area of the country (Oregon) the going rate is $50 per hour. In the UK, it is about $70/hour (US).
HTH,
jjjjjjj
1. Don't take the project if don't understand the scope.
2. Charge a rate that is agreeable. The hourly scheme is the best choice as has been mentioned above.
3. In our area of the country (Oregon) the going rate is $50 per hour. In the UK, it is about $70/hour (US).
HTH,
jjjjjjj
HTH? (Hit the hay?)
ASKER
I'm still curious if someone is trying to establish a way to calculate on forhand the final cost's.
I've been working with FPA (Function Points Analysis) and that's a way that gives a rather well insight, but you'll have to know what functions have to be build.
Nico
I've been working with FPA (Function Points Analysis) and that's a way that gives a rather well insight, but you'll have to know what functions have to be build.
Nico
"Hope this helps." (That will cost you 50 points :)!!!!!
*wry smile*... You damn well ought to be expensive, nico...
There's an old story about an optician, who was asked how he priced his glasses.
"Well, first I tell the customer that his glasses will cost $100.
"If he doesn't blink, I tell him, 'Of course, that's just for the frames. The lenses will cost you another $100.'
"And if he doesn't blink, I tell him, 'Each.'"
There's an old story about an optician, who was asked how he priced his glasses.
"Well, first I tell the customer that his glasses will cost $100.
"If he doesn't blink, I tell him, 'Of course, that's just for the frames. The lenses will cost you another $100.'
"And if he doesn't blink, I tell him, 'Each.'"
Depends...
$1.29 for a pack of index cards at the local office products store.
$15/hr for a student who doesn't know a normal form from a tax form
$30/hr for a beginning career type who has a job and wants to "test the water"
$200/hr for someone who can take you all the way to an IPO...
$1.29 for a pack of index cards at the local office products store.
$15/hr for a student who doesn't know a normal form from a tax form
$30/hr for a beginning career type who has a job and wants to "test the water"
$200/hr for someone who can take you all the way to an IPO...
ASKER
The comment of dbalaski on the original database question:
Nico5038 -- Yes, you are correct .. I do have an "learned" distrust of "contract" developers.
Reason being -- is that I've seen too many phonies try to pass off Horrible Solutions.
I have one vendor tell me "I used to work for Oracle -- i know what I am talking about" (after reviewing his application, I can see why working for Oracle was in the PAST TENSE).
His application had the Following:
1) 33 out of 60 tables using reserved words, such as:
DATE, TYPE, VALUE, START, COMPLETE, TO... (you can use reserve words for column names in Oracle if you place them in " " ).
There was a set of columns named "X1" thru "X100"
(yeah -- this is really good data modeling! NOT)
2) No Foreign Keys -- this is okay since there were no primary keys
3) 28 tables (out of 60) without any form of index
When I asked about why there were no primary keys -- he quipped back that primary keys are really unique indexes and that unique indexes cause problems. My response: okay, then why do you have 25 unique indexes spread across 7 tables?
That was another vendor i have seen -- believe it or not, a different vendor than I cited in my original response to this question.
I have seen great developers -- i have seen alot of the opposite. I know enough that real 5th normal form data modeling is really an Art form that is very difficult. You need the right talent for the right solution.
just my feedback and justified cynicism,
dB
Nico5038 -- Yes, you are correct .. I do have an "learned" distrust of "contract" developers.
Reason being -- is that I've seen too many phonies try to pass off Horrible Solutions.
I have one vendor tell me "I used to work for Oracle -- i know what I am talking about" (after reviewing his application, I can see why working for Oracle was in the PAST TENSE).
His application had the Following:
1) 33 out of 60 tables using reserved words, such as:
DATE, TYPE, VALUE, START, COMPLETE, TO... (you can use reserve words for column names in Oracle if you place them in " " ).
There was a set of columns named "X1" thru "X100"
(yeah -- this is really good data modeling! NOT)
2) No Foreign Keys -- this is okay since there were no primary keys
3) 28 tables (out of 60) without any form of index
When I asked about why there were no primary keys -- he quipped back that primary keys are really unique indexes and that unique indexes cause problems. My response: okay, then why do you have 25 unique indexes spread across 7 tables?
That was another vendor i have seen -- believe it or not, a different vendor than I cited in my original response to this question.
I have seen great developers -- i have seen alot of the opposite. I know enough that real 5th normal form data modeling is really an Art form that is very difficult. You need the right talent for the right solution.
just my feedback and justified cynicism,
dB
nico
I am the unusual programmer. My background is business, and it doesn't correspond with programmers who say I can't give you a price up front. If you think a builder who builds a custom home knows everything that is going to go wrong in the building process, you do not know custom builders. (I will come back to the builder in a minute.)
From my point of view, If you are a programmer working for an IT department, the answer is by the hour.
If you are a programmer working for a non IT department of a business that is not the way to go. You will have unhappy people eventually and you will do one or 2 projects and go down the road. It will always cost more than they thought, and it will not have everything they thought would be part of the project.
A business needs to know the cost of anything before they can decide if the pay back is there for the project. So if you can give them a cost (I never talk dollars, I only talk hours. And my hours would be stated in a range --> “between 175 hours and 220 hours”) they can make that decision. If you can deliver the programs on time for the cost you state you become their buddy. You also become the one they want to work with (I am scheduled to February 2001 and only have 4 customers – I wonder why?)
How do you accomplish this? As Brian stated “If that task is really well defined, the price is usually set.”
>>You<< Define the project before it starts. Remember that custom builder. He wouldn’t start building that house if he/she did not have complete blue prints and a contract. And by the way I don’t know of any architects that would do the blue prints for free.
My way of doing business:
If you are a new client I will give you an hour or 2 free to sit down and talk about your project. I will try to scare you with the cost. I will let you know that even if we design and build this program, you will spend more money as time goes on, because the best programs are growing projects that keep saving the client more time and making the client more money.
Once you got your first hour or 2 free, No More Free Time. I will bid your project with complete blueprints to tables, forms, and reports. When I get finished you could hire someone else to build your project. I charge for this process. I can do most bids for small to medium projects in 15 to 20 hours because of past experience.
Once the blue prints are finished, you can hire me or not. (I’ve always got hired with one exception where they did not go forward with the project.) I will have the maximum hours it will take, I will make it clear that if they want to change the blue print, there will be a cost.
This is what works for me. I think you will find I am very much in the minority and very much in demand.
Good Luck
Larry
I am the unusual programmer. My background is business, and it doesn't correspond with programmers who say I can't give you a price up front. If you think a builder who builds a custom home knows everything that is going to go wrong in the building process, you do not know custom builders. (I will come back to the builder in a minute.)
From my point of view, If you are a programmer working for an IT department, the answer is by the hour.
If you are a programmer working for a non IT department of a business that is not the way to go. You will have unhappy people eventually and you will do one or 2 projects and go down the road. It will always cost more than they thought, and it will not have everything they thought would be part of the project.
A business needs to know the cost of anything before they can decide if the pay back is there for the project. So if you can give them a cost (I never talk dollars, I only talk hours. And my hours would be stated in a range --> “between 175 hours and 220 hours”) they can make that decision. If you can deliver the programs on time for the cost you state you become their buddy. You also become the one they want to work with (I am scheduled to February 2001 and only have 4 customers – I wonder why?)
How do you accomplish this? As Brian stated “If that task is really well defined, the price is usually set.”
>>You<< Define the project before it starts. Remember that custom builder. He wouldn’t start building that house if he/she did not have complete blue prints and a contract. And by the way I don’t know of any architects that would do the blue prints for free.
My way of doing business:
If you are a new client I will give you an hour or 2 free to sit down and talk about your project. I will try to scare you with the cost. I will let you know that even if we design and build this program, you will spend more money as time goes on, because the best programs are growing projects that keep saving the client more time and making the client more money.
Once you got your first hour or 2 free, No More Free Time. I will bid your project with complete blueprints to tables, forms, and reports. When I get finished you could hire someone else to build your project. I charge for this process. I can do most bids for small to medium projects in 15 to 20 hours because of past experience.
Once the blue prints are finished, you can hire me or not. (I’ve always got hired with one exception where they did not go forward with the project.) I will have the maximum hours it will take, I will make it clear that if they want to change the blue print, there will be a cost.
This is what works for me. I think you will find I am very much in the minority and very much in demand.
Good Luck
Larry
ASKER
Larry,
Excellent! That's the way I think it should be done. When builders can, why can't we !
I've been coaching for some years a technical design course that trained the "designers to be", to estimate for each step a number of hours. In the course you saw improvement, in practice they stopped doing this as they returned to the original workplace,as it's not customary to do!
In my experience the planning (using the same tools!) should be getting more and more reliable if you keep record of estimated and realized hours.
That's why I expected that the independently working experts here, (using f.i. MS Access and/or VB) would grab the opportunity to record what they planned and what they used, to be able to forecast the time needed for a database to be created.
I'm just a "nine-to-five" slave, with a computer addiction. But I like to theorize about how to develop software as professionally and as fast as possible. That's why I'm interested in repositories, Frameworks, building blocks, software-agent technology, etc.
Part of that is ofcourse how to keep control about what you are planning to do.
Larry, do you keep record of estimated and realized hours?
Nico
Excellent! That's the way I think it should be done. When builders can, why can't we !
I've been coaching for some years a technical design course that trained the "designers to be", to estimate for each step a number of hours. In the course you saw improvement, in practice they stopped doing this as they returned to the original workplace,as it's not customary to do!
In my experience the planning (using the same tools!) should be getting more and more reliable if you keep record of estimated and realized hours.
That's why I expected that the independently working experts here, (using f.i. MS Access and/or VB) would grab the opportunity to record what they planned and what they used, to be able to forecast the time needed for a database to be created.
I'm just a "nine-to-five" slave, with a computer addiction. But I like to theorize about how to develop software as professionally and as fast as possible. That's why I'm interested in repositories, Frameworks, building blocks, software-agent technology, etc.
Part of that is ofcourse how to keep control about what you are planning to do.
Larry, do you keep record of estimated and realized hours?
Nico
Nico
1) Do you keep record of estimated and realized hours?
>>>Absolutely, positively. I track each project from bid to delivery. I also give 60 days of technical support, so I track that also. Just a note about technical support. I stated I quote hours, e.g. “between 175 hours and 220 hours”. I would never bill for 220 hours even if I spent that much time, I would bill for maybe 200. That way they are paying for support, and don’t call at each whim. If they knew their cost wouldn’t go up, there are people who would call twice a day.
2) You talk about “using the same tools” and having “repositories, Frameworks, building blocks…
>>>The concept I have is to write all code generically. The bad side of this is that it cost my customers more because writing code so it can be used in any project takes 20% to 30% longer. The good side of this is once a generic piece of code is built, I do not charge the next customer for using it.
A couple of examples of this are:
A) Query by form: I have a query by form system where a user can query on combination of one or more fields I add to the form. They can search for a value, a value that starts with characters they type, between two values, >, < , in list etc. My users love this form and the most complicated query form (3 pages) takes less than 6 hours to build.
B) Faxing: I set up faxing/emailing with WinFax/OutLook. I can fax or e-mail(e-mail is snapshot) reports. One at a time or in a couple of situations, 300 to 400 at a time – all different reports. To do this now takes about 1 to 2 hours to set up.
Nico, I could go on and on, however I think you see what works for me.
Larry
1) Do you keep record of estimated and realized hours?
>>>Absolutely, positively. I track each project from bid to delivery. I also give 60 days of technical support, so I track that also. Just a note about technical support. I stated I quote hours, e.g. “between 175 hours and 220 hours”. I would never bill for 220 hours even if I spent that much time, I would bill for maybe 200. That way they are paying for support, and don’t call at each whim. If they knew their cost wouldn’t go up, there are people who would call twice a day.
2) You talk about “using the same tools” and having “repositories, Frameworks, building blocks…
>>>The concept I have is to write all code generically. The bad side of this is that it cost my customers more because writing code so it can be used in any project takes 20% to 30% longer. The good side of this is once a generic piece of code is built, I do not charge the next customer for using it.
A couple of examples of this are:
A) Query by form: I have a query by form system where a user can query on combination of one or more fields I add to the form. They can search for a value, a value that starts with characters they type, between two values, >, < , in list etc. My users love this form and the most complicated query form (3 pages) takes less than 6 hours to build.
B) Faxing: I set up faxing/emailing with WinFax/OutLook. I can fax or e-mail(e-mail is snapshot) reports. One at a time or in a couple of situations, 300 to 400 at a time – all different reports. To do this now takes about 1 to 2 hours to set up.
Nico, I could go on and on, however I think you see what works for me.
Larry
ASKER
Larry,
In Holland we have an expression:
"A white raven" for indicating someone who's performing above average. I think your an example in that way.
Would like to hear from the others or they could (try) to work in such a way!
Nico
In Holland we have an expression:
"A white raven" for indicating someone who's performing above average. I think your an example in that way.
Would like to hear from the others or they could (try) to work in such a way!
Nico
I'll be commenting in a bit, but I list the link to this stoopid Q so I'm commenting now in order that EE sends me a link the next time someone else comments. Nico: Since you wanted to hear from me, how 'bout posting a dummy comment so I get a nitification? Thx...brb
Okay, I'm kinda tired, but here goes...
(Hold on to your hats, I couldn't stop after my fingers started flying!)
The company I used to work for, Computer Partners Unlimited, or CPU, started out doing fixed bids (before my time). I ended up supporting one of those applications long-term (the original developer left). The app was originally developed for a fixed price of $1,000. At any early time when I was doing a few hours of work on the app we billed the client $65/hour. He was very understanding, but did make the comment that support was costing him as much as the original project. Me (paraphrasing): "Yup, you got one heck of a deal. That was before we learned not to fixed-bid projects. <smile>" By the way... my boss told me that on those early projects they lost their ass.
Best stuff I read (above) so far is by LJG and his "builder" analogy...
>>>"Remember that custom builder. He wouldn’t start building that house if he/she did not have complete blue prints and a contract. And by the way I don’t know of any architects that would do the blue prints for free."
Another interesting phenomenon. As I left CPU a month ago, we were finally thinking about not even doing "free" quotes. Well, I was anyway. Typically the scenario has gone like this for the past three years: 1st (& maybe 2nd) meeting with the client we get a fair idea of what they want. Then I'd say, "You have two options: First one is for us to give you a _free_ quote. That would be a ballpark figure based on the little information we have so far and I would expect it to be fairly inaccurate. Second option is that you pay for a quote. We'd probably spend [10 to 30] hours analyzing your situation. This will cost you $70/hour. In the process we will create a database structure for the project. It's our philosophy that *everything* hinges on good database design. There are very few projects that can succeed on a bad database. When we're done, you can even take that database to another shop/programmer and have them follow through with the development. The paid quote will be highly accurate." In almost every single case the potential client goes with the free quote. And I have had several of the prospects tell me that even the free one was incredibly detailed compared to the quotes they got from the competition! And what happens after the free quote? A fair number of times we don't get the job. Not sure why. I *do* know that there are a number of less experienced programmers *and* shops that don't know their butt from a hole in the ground; I think we've lost to a fair number of the jobs because their quotes were lower. Actually, _we_ didn't lose, the prospect did. They're the ones getting the shaft from less experienced developers and less reliable quotes. (In case you're wondering, Yes, I *am* sure of that!) The other result of a free quote is that we *do* get the job. And it runs WAY over the customer's perceived "budget." I say "perceived" and loosely use the term "budget" because that free quote ain't no stinkin' "budget." It's a "wag." A "guess." "Ballpark." "Shot in the dark." I'm ticked because I've been called into these clients offices (usually the business owner) and reemed out. Tough. I tell them over and over and over "Y-O-U chose to be a cheap ass and not pay for a spec! That was Y-O-U-R decision against OUR better judgement." Okay, I don't say it *that* way, but I *do* get the point across. A lot of good that does after they perceive that they've blown an extra $3,000 or $15,000 on a project.
Now that I'm on my own, I hope I can put my foot down and say, "You will pay for a quote or you won't get one. It's not fair to either one of us for me to pull a number out of the sky and be held accountable for it." Just a couple days ago I was on the verge of spending a significant amount of resources (time) investigating modifications to an Access 2.0 accounting package. Before I did, I convinced the contact (who I'd be sub-contracting for) to talk to the client and ask them how they would feel about spending $2,000-3,000+ on modifications. I told him it would make a good litmus test. If that scared them, then they aren't in the market for my services. (Maybe some cheap college kid's, but not mine. At least not until they need me to clean up after that college kid. LOL!!!) The result? Project's on hold while they think it over. Good. None of us wasted time and expectations.
I'm darn good and I know it. And my _existing_ clients know it. In fact, most of my existing clients trust me to the point that they don't have me formally quote anything anymore. Sure, I'll give 'em a friendly guess as a litmus test and that tends to work pretty good. Lets them decide whether this or that is worth it. And I haven't had any of them complain in the end that the hours got too high because they almost always get more (functionality, flexibility) than they imagined. Again, those are my well-established clients.
The way I see it is if you have a prospect that's not willing to *invest* in a good quote, then they're probably too cheap and I don't want them as a client. Truth is, they shouldn't want me as a developer either. I don't think *any* prospect/client goes into a new project saying, "Gee, I sure hope I get to bitch about the price tag when this thing's said and done!" LOL!!
By the way, here's a pretty standard paragraph I put in the closing section of a quote:
"This is the information you requested on the amount of time it will take to develop <<project>>. Please note that these time estimates should be considered as the **minimum required.** This is because it is inevitable that other needs and issues will come up during product development. Rapid application development (RAD) is, by nature, a dynamic process, not a static one. The benefit of this approach is that you, the customer, are far more likely to get what you need and want; there are no surprises at installation time. The down side of RAD is that it is nearly impossible to predict, at the outset of a project, how much extra work might be involved **due to changes.** Therefore, it is our policy to bill all work on an hourly basis... We have found that this approach is usually to your benefit; fixed-price bids are typically more expensive than per-hour enhancements because of **pricing for the unknown.**"
(Key words/phrases emphasized in "**". I sure wish I knew how we could embed at least simple HTML in these posts...)
>>>LJG's section on "My way of doing business"
Love it. "I will try to scare you with the cost." There's that litmus test. My "blueprint" usually doesn't go any further than db layout, tho. Beyond that, to me, get's too much into "development" instead of "planning." Not that I wouldn't do it, because I have had clients request it on occasion, but it's not my standard practice. Actually, I'm shocked when clients say, "Could you slap together a quick prototype so we get some idea of where you'll be heading with this?" What that *REALLY* says is, "We are not afraid to spend a few dollars up front to make sure this will go the right direction from the outset." That's fantastic! Slap me, I'm dreaming! You mean I get to throw something together, get paid for it, and not be held totally responsible for the outcome? WooHoo!
>>>"Do you keep record of estimated and realized hours?"
Nope. First, let me tell you this: After I lay out the db and print the relationships, I don't need anything more. (Software Wizardry's Relationship Printer output to a drafting printer is awesome! Poster-sized relationship diagrams!) Each supporting table (or "lookup" as I call it - like "tblLkp_CustomerType") gets 1 hour of estimated development. Then I break down the main tables, taking into consderation how hairy the nested, multi-tiered relationships are. Reports are more difficult to estimate unless you can coax the client to give you a fair amount of detail on what they want to report on. Actually, now that I think about it, that's one of the *MOST* important aspects. "What do you want to extract from the database after you get all that data in there?" If your db design can't give the results, Mr. Developer, you're screwed.
<<This line intentionally left blank for 'spacing' BrianWren likes so much... LOL! Love ya BW!>>
After I lay out the database, I usually take it back to the client and go over it with them. I give them a basic understanding of how the data is related. I teach them how to "read" a relationship diagram, complete with standard naming conventions on tables and fields! As I'm showing them how the data is stored, the conversation naturally flows into a game of tennis. Me: "Here's where X is stored, and A, B, C about X." Client: "Where's Y?" "Here. And Here's Z, with D, E, F about it." (uh-oh, I'm out of letters...<grin>)
When we're all done going over the db and I'm done making notes, both of us are fairly confident I've covered all the bases. That thing paints 90% of the picture of the application. Period. (Okay, maybe 80%.)
>>>LJG's "The concept I have is to write all code generically."
I guess I do that. Over the years it has just become natural for me to hard-code very little of the application. Or as little as I can get away with in balancing ease of maintenance and cost. Yes, it does cost more to develop "generically." But the paybacks are immense. Not just in re-using the pieces for other applications, but also in future maintenance of *this* application. Heck, never mind maintenance, just in the on-going development! I've found that no matter WHAT you do, the user gets new ideas as you go along. And that's good! It's $moolah$. Um, that's not what I meant. 8-) If they look at what you have and say the first time, "Yup, looks good. What's next?" you should be scared. You ain't talking to the right person. Squeeze around that manager and talk to his employees, because THEY are the ones who are going to use it and THEY are the ones who are going to bitch up a storm if it ain't right.
W-H-E-W-!
Nico: Still happy I chimed in? ;-)
(Hold on to your hats, I couldn't stop after my fingers started flying!)
The company I used to work for, Computer Partners Unlimited, or CPU, started out doing fixed bids (before my time). I ended up supporting one of those applications long-term (the original developer left). The app was originally developed for a fixed price of $1,000. At any early time when I was doing a few hours of work on the app we billed the client $65/hour. He was very understanding, but did make the comment that support was costing him as much as the original project. Me (paraphrasing): "Yup, you got one heck of a deal. That was before we learned not to fixed-bid projects. <smile>" By the way... my boss told me that on those early projects they lost their ass.
Best stuff I read (above) so far is by LJG and his "builder" analogy...
>>>"Remember that custom builder. He wouldn’t start building that house if he/she did not have complete blue prints and a contract. And by the way I don’t know of any architects that would do the blue prints for free."
Another interesting phenomenon. As I left CPU a month ago, we were finally thinking about not even doing "free" quotes. Well, I was anyway. Typically the scenario has gone like this for the past three years: 1st (& maybe 2nd) meeting with the client we get a fair idea of what they want. Then I'd say, "You have two options: First one is for us to give you a _free_ quote. That would be a ballpark figure based on the little information we have so far and I would expect it to be fairly inaccurate. Second option is that you pay for a quote. We'd probably spend [10 to 30] hours analyzing your situation. This will cost you $70/hour. In the process we will create a database structure for the project. It's our philosophy that *everything* hinges on good database design. There are very few projects that can succeed on a bad database. When we're done, you can even take that database to another shop/programmer and have them follow through with the development. The paid quote will be highly accurate." In almost every single case the potential client goes with the free quote. And I have had several of the prospects tell me that even the free one was incredibly detailed compared to the quotes they got from the competition! And what happens after the free quote? A fair number of times we don't get the job. Not sure why. I *do* know that there are a number of less experienced programmers *and* shops that don't know their butt from a hole in the ground; I think we've lost to a fair number of the jobs because their quotes were lower. Actually, _we_ didn't lose, the prospect did. They're the ones getting the shaft from less experienced developers and less reliable quotes. (In case you're wondering, Yes, I *am* sure of that!) The other result of a free quote is that we *do* get the job. And it runs WAY over the customer's perceived "budget." I say "perceived" and loosely use the term "budget" because that free quote ain't no stinkin' "budget." It's a "wag." A "guess." "Ballpark." "Shot in the dark." I'm ticked because I've been called into these clients offices (usually the business owner) and reemed out. Tough. I tell them over and over and over "Y-O-U chose to be a cheap ass and not pay for a spec! That was Y-O-U-R decision against OUR better judgement." Okay, I don't say it *that* way, but I *do* get the point across. A lot of good that does after they perceive that they've blown an extra $3,000 or $15,000 on a project.
Now that I'm on my own, I hope I can put my foot down and say, "You will pay for a quote or you won't get one. It's not fair to either one of us for me to pull a number out of the sky and be held accountable for it." Just a couple days ago I was on the verge of spending a significant amount of resources (time) investigating modifications to an Access 2.0 accounting package. Before I did, I convinced the contact (who I'd be sub-contracting for) to talk to the client and ask them how they would feel about spending $2,000-3,000+ on modifications. I told him it would make a good litmus test. If that scared them, then they aren't in the market for my services. (Maybe some cheap college kid's, but not mine. At least not until they need me to clean up after that college kid. LOL!!!) The result? Project's on hold while they think it over. Good. None of us wasted time and expectations.
I'm darn good and I know it. And my _existing_ clients know it. In fact, most of my existing clients trust me to the point that they don't have me formally quote anything anymore. Sure, I'll give 'em a friendly guess as a litmus test and that tends to work pretty good. Lets them decide whether this or that is worth it. And I haven't had any of them complain in the end that the hours got too high because they almost always get more (functionality, flexibility) than they imagined. Again, those are my well-established clients.
The way I see it is if you have a prospect that's not willing to *invest* in a good quote, then they're probably too cheap and I don't want them as a client. Truth is, they shouldn't want me as a developer either. I don't think *any* prospect/client goes into a new project saying, "Gee, I sure hope I get to bitch about the price tag when this thing's said and done!" LOL!!
By the way, here's a pretty standard paragraph I put in the closing section of a quote:
"This is the information you requested on the amount of time it will take to develop <<project>>. Please note that these time estimates should be considered as the **minimum required.** This is because it is inevitable that other needs and issues will come up during product development. Rapid application development (RAD) is, by nature, a dynamic process, not a static one. The benefit of this approach is that you, the customer, are far more likely to get what you need and want; there are no surprises at installation time. The down side of RAD is that it is nearly impossible to predict, at the outset of a project, how much extra work might be involved **due to changes.** Therefore, it is our policy to bill all work on an hourly basis... We have found that this approach is usually to your benefit; fixed-price bids are typically more expensive than per-hour enhancements because of **pricing for the unknown.**"
(Key words/phrases emphasized in "**". I sure wish I knew how we could embed at least simple HTML in these posts...)
>>>LJG's section on "My way of doing business"
Love it. "I will try to scare you with the cost." There's that litmus test. My "blueprint" usually doesn't go any further than db layout, tho. Beyond that, to me, get's too much into "development" instead of "planning." Not that I wouldn't do it, because I have had clients request it on occasion, but it's not my standard practice. Actually, I'm shocked when clients say, "Could you slap together a quick prototype so we get some idea of where you'll be heading with this?" What that *REALLY* says is, "We are not afraid to spend a few dollars up front to make sure this will go the right direction from the outset." That's fantastic! Slap me, I'm dreaming! You mean I get to throw something together, get paid for it, and not be held totally responsible for the outcome? WooHoo!
>>>"Do you keep record of estimated and realized hours?"
Nope. First, let me tell you this: After I lay out the db and print the relationships, I don't need anything more. (Software Wizardry's Relationship Printer output to a drafting printer is awesome! Poster-sized relationship diagrams!) Each supporting table (or "lookup" as I call it - like "tblLkp_CustomerType") gets 1 hour of estimated development. Then I break down the main tables, taking into consderation how hairy the nested, multi-tiered relationships are. Reports are more difficult to estimate unless you can coax the client to give you a fair amount of detail on what they want to report on. Actually, now that I think about it, that's one of the *MOST* important aspects. "What do you want to extract from the database after you get all that data in there?" If your db design can't give the results, Mr. Developer, you're screwed.
<<This line intentionally left blank for 'spacing' BrianWren likes so much... LOL! Love ya BW!>>
After I lay out the database, I usually take it back to the client and go over it with them. I give them a basic understanding of how the data is related. I teach them how to "read" a relationship diagram, complete with standard naming conventions on tables and fields! As I'm showing them how the data is stored, the conversation naturally flows into a game of tennis. Me: "Here's where X is stored, and A, B, C about X." Client: "Where's Y?" "Here. And Here's Z, with D, E, F about it." (uh-oh, I'm out of letters...<grin>)
When we're all done going over the db and I'm done making notes, both of us are fairly confident I've covered all the bases. That thing paints 90% of the picture of the application. Period. (Okay, maybe 80%.)
>>>LJG's "The concept I have is to write all code generically."
I guess I do that. Over the years it has just become natural for me to hard-code very little of the application. Or as little as I can get away with in balancing ease of maintenance and cost. Yes, it does cost more to develop "generically." But the paybacks are immense. Not just in re-using the pieces for other applications, but also in future maintenance of *this* application. Heck, never mind maintenance, just in the on-going development! I've found that no matter WHAT you do, the user gets new ideas as you go along. And that's good! It's $moolah$. Um, that's not what I meant. 8-) If they look at what you have and say the first time, "Yup, looks good. What's next?" you should be scared. You ain't talking to the right person. Squeeze around that manager and talk to his employees, because THEY are the ones who are going to use it and THEY are the ones who are going to bitch up a storm if it ain't right.
W-H-E-W-!
Nico: Still happy I chimed in? ;-)
Just a couple of comments on Believer’s thoughts.
I will give them a Wild Guess for free on the first visit (the free one). I usually come up with a figure in my mind that I’m absolutely sure of, then I times it times 3. Remember I want to scare them. However I would >>>>Never<<<< >>>>Ever<<<< do a job without a >>Complete<< quote. They don’t want me if they do not understand that the process starts with a complete workup of their project. If I scared them but they still want me to go forward, I did my job well. Who I want is someone who is committed to doing a project (with me or someone else), the cost for a blueprint, for these type of clients, will be a no brainer.
Believer you talk about your "blueprint usually doesn't go any further than db layout”. I disagree. I don’t show a database layout and relationship the way you and I would talk to each other, It would mean nothing to my clients. I divide the project up into forms. Then I show the fields from each form and the tables they come from. This shows the relationship between the tables, however not in the way you and I would talk. For the forms I show combo boxes, and examples of data would be in the combo and fields that would be filled in.
I will not show what the form looks like, that is part of development. But I do the above for each form. This really let’s the user see what we are putting together.
I also give them the following on a bid. a copy of a combo box, check box, examples of how the Query screen would look and work on each form, and how you print reports based on records you lookup through the query screen.
On reports, I get some example data from the client (Things always looks better and make sense to the client if they see data that they are use to). Then I go into Excel and build actual reports. These reports look 90% like the report will look like in Access. This is an important aspect of bidding from my point of view. If you understand what the client wants on the reports, you are ready to build the database.
Next I document any process that is not form/report related. We then go over all the fields on the forms, and the reports. I get input from them (hopefully this is the users and the owner – If not I have a problem). This input will cause 10% to 15% changes. Then we are ready to sign a contract.
Once I go through the process, I do not go back to the client in the middle of the process unless I have a question. I do not want them to change the bid until I get it installed.
By them paying for the process and being involved in the process, I’m the guy they want to go with. My biggest problem is “When can we schedule this to be done”. I now have a problem that I can’t start a new project for 8 months. This is the killer, not the bid process. (By the way I am not taking on any new customers and have not been for over a year.)
You stated you are darn good and my existing clients know it. That’s the secret in my opinion. “If you do what you say you are going to do, when you say you are going to do it”, you have a client for life.
Believer, you talk about getting additional future work when “the user gets new ideas as you go along”. That’s great, but another idea is to get to know your clients process as well as they do. Once you know this, you can make suggestions to them. About 2 weeks after installation, I usually give my clients a couple of pages of additions they might be interest in. In 70% of the cases, they take me up on some of my ideas.
Just some thought
Larry
I will give them a Wild Guess for free on the first visit (the free one). I usually come up with a figure in my mind that I’m absolutely sure of, then I times it times 3. Remember I want to scare them. However I would >>>>Never<<<< >>>>Ever<<<< do a job without a >>Complete<< quote. They don’t want me if they do not understand that the process starts with a complete workup of their project. If I scared them but they still want me to go forward, I did my job well. Who I want is someone who is committed to doing a project (with me or someone else), the cost for a blueprint, for these type of clients, will be a no brainer.
Believer you talk about your "blueprint usually doesn't go any further than db layout”. I disagree. I don’t show a database layout and relationship the way you and I would talk to each other, It would mean nothing to my clients. I divide the project up into forms. Then I show the fields from each form and the tables they come from. This shows the relationship between the tables, however not in the way you and I would talk. For the forms I show combo boxes, and examples of data would be in the combo and fields that would be filled in.
I will not show what the form looks like, that is part of development. But I do the above for each form. This really let’s the user see what we are putting together.
I also give them the following on a bid. a copy of a combo box, check box, examples of how the Query screen would look and work on each form, and how you print reports based on records you lookup through the query screen.
On reports, I get some example data from the client (Things always looks better and make sense to the client if they see data that they are use to). Then I go into Excel and build actual reports. These reports look 90% like the report will look like in Access. This is an important aspect of bidding from my point of view. If you understand what the client wants on the reports, you are ready to build the database.
Next I document any process that is not form/report related. We then go over all the fields on the forms, and the reports. I get input from them (hopefully this is the users and the owner – If not I have a problem). This input will cause 10% to 15% changes. Then we are ready to sign a contract.
Once I go through the process, I do not go back to the client in the middle of the process unless I have a question. I do not want them to change the bid until I get it installed.
By them paying for the process and being involved in the process, I’m the guy they want to go with. My biggest problem is “When can we schedule this to be done”. I now have a problem that I can’t start a new project for 8 months. This is the killer, not the bid process. (By the way I am not taking on any new customers and have not been for over a year.)
You stated you are darn good and my existing clients know it. That’s the secret in my opinion. “If you do what you say you are going to do, when you say you are going to do it”, you have a client for life.
Believer, you talk about getting additional future work when “the user gets new ideas as you go along”. That’s great, but another idea is to get to know your clients process as well as they do. Once you know this, you can make suggestions to them. About 2 weeks after installation, I usually give my clients a couple of pages of additions they might be interest in. In 70% of the cases, they take me up on some of my ideas.
Just some thought
Larry
ASKER
Dave (Believer) & Larry,
Wooooooow!
That's what I was looking for!
I was surprised that Dave found out (during typing) that Reports were important !
The development method I use for over 20 years is called data-driven (as opposite to process-driven) and like both of you do place the data(base) in the centre of development. Best reason:
Data is stable, processes aren't (Just think or reorganisations within a bank, the processes (frontoffice/backoffice f.i.) can change, the clients and accounts will still be there!
To get the data needed this development method starts with..... all output !
(Both reports and forms/screens)
By tracing the algorithms behind the sometimes "constructed" output fields, then the original "basic" fields are found that need to be stored.
My collegues sometimes did try to use the datamodel as a basis to talk to the client, they found out (like Larry) that that doesn't work. I myself call a datamodel an expert-model and only use it in discussions about normalisation with my collegues. For the customer I make a user-model. Much simpler (no connection tables, etc) and named in his terminology. (I work most of the time for larger companies and sometimes the departments have different names for the same entities and sometimes the same name for different entities!)
Since I saw the UML development method with User Scripts, I must say that that's rather close to my "user-model" idea.
For the generic code part, did either of you tried a repository?
I've been working with two types of tools that were repository driven and I must say I miss the first one the most.
That one created a system "on-the-fly" from the metadatamodel you filled as a developer. It was a mainframe tool and I created a sample application working on VSAM and changed it to the ADABAS dbms within 2 hours.
Ask a standard development department (or you) to change the database from X to Y (lets say Access to MS SQL) and make an estimate the costs....
Then change your mind and change it to MySQL. With that tool I would do it within a morning !
I'm still thinking that being a professional you should try to measure as that's the only way to be able to estimate future applications. As I see it, in each professional region that's done. Take f.i. professional sports and see what they invest in measuring and R&D to optimize everything to get the best chances for records!
I'm I typing too much?
Enough spacelines Brian ?
Nico
Wooooooow!
That's what I was looking for!
I was surprised that Dave found out (during typing) that Reports were important !
The development method I use for over 20 years is called data-driven (as opposite to process-driven) and like both of you do place the data(base) in the centre of development. Best reason:
Data is stable, processes aren't (Just think or reorganisations within a bank, the processes (frontoffice/backoffice f.i.) can change, the clients and accounts will still be there!
To get the data needed this development method starts with..... all output !
(Both reports and forms/screens)
By tracing the algorithms behind the sometimes "constructed" output fields, then the original "basic" fields are found that need to be stored.
My collegues sometimes did try to use the datamodel as a basis to talk to the client, they found out (like Larry) that that doesn't work. I myself call a datamodel an expert-model and only use it in discussions about normalisation with my collegues. For the customer I make a user-model. Much simpler (no connection tables, etc) and named in his terminology. (I work most of the time for larger companies and sometimes the departments have different names for the same entities and sometimes the same name for different entities!)
Since I saw the UML development method with User Scripts, I must say that that's rather close to my "user-model" idea.
For the generic code part, did either of you tried a repository?
I've been working with two types of tools that were repository driven and I must say I miss the first one the most.
That one created a system "on-the-fly" from the metadatamodel you filled as a developer. It was a mainframe tool and I created a sample application working on VSAM and changed it to the ADABAS dbms within 2 hours.
Ask a standard development department (or you) to change the database from X to Y (lets say Access to MS SQL) and make an estimate the costs....
Then change your mind and change it to MySQL. With that tool I would do it within a morning !
I'm still thinking that being a professional you should try to measure as that's the only way to be able to estimate future applications. As I see it, in each professional region that's done. Take f.i. professional sports and see what they invest in measuring and R&D to optimize everything to get the best chances for records!
I'm I typing too much?
Enough spacelines Brian ?
Nico
I have to stop writing books and get back to work. However just a note on "did either of you tried a repository" - No
I use code in modules in Access that I version. As I change versions (Which I do all the time) I show what needs to be changed in the database (if anything) to make the new version work. So if I go back to a project I finished a year ago, I will import the newest and greatest version, and then make any changes needed to the database. I always try to make all Generic Modules, backward compatible.
Larry
I use code in modules in Access that I version. As I change versions (Which I do all the time) I show what needs to be changed in the database (if anything) to make the new version work. So if I go back to a project I finished a year ago, I will import the newest and greatest version, and then make any changes needed to the database. I always try to make all Generic Modules, backward compatible.
Larry
I'll have to see if/when I get time to come back to this... gut reaction is I don't have much to add, but then I also didn't know I was going to write so much the first time!
I always work with project teams and I sell an analysis first.
Depending on the size of the project this can take 2 days till a month.
Depending on the result of this analysis, the customer then gets a fair good idea about the time we expect to need for building the solution. Then, we come with a team and everybody bills on an hourly base, depending on the developers/consultants level. A senior consultant rate is about 150$/hour, a very junior developer about 85$/hour.
Say, another question, how many of you succeed in building a solution in the time they expect and plan to do ?
regards, Ivan
Depending on the size of the project this can take 2 days till a month.
Depending on the result of this analysis, the customer then gets a fair good idea about the time we expect to need for building the solution. Then, we come with a team and everybody bills on an hourly base, depending on the developers/consultants level. A senior consultant rate is about 150$/hour, a very junior developer about 85$/hour.
Say, another question, how many of you succeed in building a solution in the time they expect and plan to do ?
regards, Ivan
ASKER
Ivan,
I've done a lot of projects, but I always had the planning disadvantage that I had to work with methods and tools that were new to me. So it's hard to build up experience to be able to give an accurate planning.
However, I normally start a project by making a planning that's broken down in sizeble units between 2 hrs and a max of some 16 till 24 hours. This enables me to see in an early stage whether the planning is realistic or not, so an early alarm can be given to the management/client when things tend to go wrong.
The size enables each week to see whether or not I'm on schedule.
The main problem of such a planning is the need for fixed products to be delivered. It tends to make it rather inflexible to change the schema half way. Therefor I'm more and more convinced that the best way of development will be splitting the project into "black boxes" of a 3 months timespan at most. It should deliver a product (documentation) or working application, that's not finished, but "working" with the bare necessities. Thus the user/client has something to evaluate and to be able to re-target the ultimate goal.
As hard it is for us to estimate the cost, it's also hard for a user to specify his wishes when he has nothing working to critisize.
Nico
I've done a lot of projects, but I always had the planning disadvantage that I had to work with methods and tools that were new to me. So it's hard to build up experience to be able to give an accurate planning.
However, I normally start a project by making a planning that's broken down in sizeble units between 2 hrs and a max of some 16 till 24 hours. This enables me to see in an early stage whether the planning is realistic or not, so an early alarm can be given to the management/client when things tend to go wrong.
The size enables each week to see whether or not I'm on schedule.
The main problem of such a planning is the need for fixed products to be delivered. It tends to make it rather inflexible to change the schema half way. Therefor I'm more and more convinced that the best way of development will be splitting the project into "black boxes" of a 3 months timespan at most. It should deliver a product (documentation) or working application, that's not finished, but "working" with the bare necessities. Thus the user/client has something to evaluate and to be able to re-target the ultimate goal.
As hard it is for us to estimate the cost, it's also hard for a user to specify his wishes when he has nothing working to critisize.
Nico
Nico,
I totally agree. And the key to that is, IMHO, an analysis (or call it a FPA) that brakes down the problem into Access objects and functions
So : 1 client input form --> 4 WFH
1 summary report --> 8 WFH
(WFH-WorkForceHours)
This way I can monitor the teams progress and the over/underrun on certain FP.
If a user has an additional comment, we send out a change request form. It states that the user asks something that is not included in the original FPA and that there are two options :
A/ We throw something else out of the scope so the project stays on budget
B/ We include the new item in the scope but then the scope broadens so budget raises and time to complete is set back. The client has to sign off this document.
This way we have at least a paper trail of why we don't stay on budget and who's responsible.
Formalities, the key to good customer relationships !
regards, Ivan
I totally agree. And the key to that is, IMHO, an analysis (or call it a FPA) that brakes down the problem into Access objects and functions
So : 1 client input form --> 4 WFH
1 summary report --> 8 WFH
(WFH-WorkForceHours)
This way I can monitor the teams progress and the over/underrun on certain FP.
If a user has an additional comment, we send out a change request form. It states that the user asks something that is not included in the original FPA and that there are two options :
A/ We throw something else out of the scope so the project stays on budget
B/ We include the new item in the scope but then the scope broadens so budget raises and time to complete is set back. The client has to sign off this document.
This way we have at least a paper trail of why we don't stay on budget and who's responsible.
Formalities, the key to good customer relationships !
regards, Ivan
I track each hour of the project. The entire process falls apart if you don't look at what you did right and what you did wrong at the end of the process.
I agree totally with IvanD "If a user has an additional comment, we send out a change request form." By doing this you can stay in budget (budget and time are the same if your billing by the hour).
Because of my past experience, my library of objects, and the fact I have the luxury to over bid if in question, I have very little problems staying in budget. The exception to this, is when I come up on something I want to learn a lot more than is necessary for the project
thanks
Larry
I agree totally with IvanD "If a user has an additional comment, we send out a change request form." By doing this you can stay in budget (budget and time are the same if your billing by the hour).
Because of my past experience, my library of objects, and the fact I have the luxury to over bid if in question, I have very little problems staying in budget. The exception to this, is when I come up on something I want to learn a lot more than is necessary for the project
thanks
Larry
"...how many of you succeed in building a solution in the time they expect and plan to do ?"
Now that's a loaded question... LOL!
Almost never. Why? I frequently find myself shooting at moving targets. I've come to expect that it's par for the course: The user can't possible visualize everything they'll want from the outset. It's lot like questions on EE. Frequently a Q is asked and some answers come to mind. But as the answerers get more info, the answer tends to change. In the same way, the more the user sees what _can_ be done or _how_ things can be done, the more ideas they get. Their own visualization of a "solution" becomes clearer and clearer.
This is partly why it is so important for a formal, paid, scope/quote/plan needs to be done. The more *I* know as a developer about what it is they are trying to accomplish, the better I can do at giving them what they **need**.
There's a BIG difference between what they need and what they want. My guess is that 80-90% of clients know (or think they know) what they "want," but very few know what they "need." Therein lies the value of my services! I am constantly looking to give customers what they NEED. Unfortunately, it's harder to convince some than others of this. (At the risk of repeating myself...) The absolute worst projects I've ever had are the ones where the user is continually telling me "Here's what I want... No, that's not what I wanted, I want *this*... That looks okay, but now I want it *this* way..." What a nightmare. In most cases, the projects that end up going that way are the ones that are re-writes of an existing system. Users have been using the same (DOS) app for 10 years and they do NOT want to change. Instead of adapting to a streamlined Windows-type interface, they end up asking for a DOS-like app that runs in Windows.
Here's a loaded answer for the loaded Q <grin>:
"...how many of you succeed in building a solution in the time they expect and plan to do ?"
I do, 90%. BUT... It is my *thorough* estimates are highly accurate with respect to *my* understanding of the application. Quick & dirty "free" estimates are rarely on target. And "my" understanding of the application (or problem) isn't what counts - what counts is the _user's_ perception of how well my solution solves the _actual_ problem. That's why extensive analysis is so important!
My car is making an odd noise and I need to get it into the shop. I'm well aware that it's nearly impossible for me to call the garage and explain the problem and get an accurate estimate of what it'll cost to fix it. The best I'll probably get is "well, it could be this, this, or this..." If I take it in a let them listen to it, they'll have an even better idea of what's wrong. But ultimately it's when I let them put the car up on the rack and have a look around that they'll do the best job of diagnosing the problem. And even if I choose not to have them fix it, I'll probably owe some $$ for the diagnosis. Is it worth it? If I get the correct diagnosis for the problem, absolutely! What if I choose to rely on an ever-the-phone guess about what's wrong and pay nothing? Then I take the car in to have the work done and the problem is far more serious (read: expensive) than I was led to believe. Will I be upset with the bill? Absolutely!
Gee, now that I think about it, I'm probably "preaching to the choir." The audience I really need is my current and future clients! That's why some of the commentary in here may well end up on my website some day! (When I get around to creating one, that is. <chuckle>)
Now that's a loaded question... LOL!
Almost never. Why? I frequently find myself shooting at moving targets. I've come to expect that it's par for the course: The user can't possible visualize everything they'll want from the outset. It's lot like questions on EE. Frequently a Q is asked and some answers come to mind. But as the answerers get more info, the answer tends to change. In the same way, the more the user sees what _can_ be done or _how_ things can be done, the more ideas they get. Their own visualization of a "solution" becomes clearer and clearer.
This is partly why it is so important for a formal, paid, scope/quote/plan needs to be done. The more *I* know as a developer about what it is they are trying to accomplish, the better I can do at giving them what they **need**.
There's a BIG difference between what they need and what they want. My guess is that 80-90% of clients know (or think they know) what they "want," but very few know what they "need." Therein lies the value of my services! I am constantly looking to give customers what they NEED. Unfortunately, it's harder to convince some than others of this. (At the risk of repeating myself...) The absolute worst projects I've ever had are the ones where the user is continually telling me "Here's what I want... No, that's not what I wanted, I want *this*... That looks okay, but now I want it *this* way..." What a nightmare. In most cases, the projects that end up going that way are the ones that are re-writes of an existing system. Users have been using the same (DOS) app for 10 years and they do NOT want to change. Instead of adapting to a streamlined Windows-type interface, they end up asking for a DOS-like app that runs in Windows.
Here's a loaded answer for the loaded Q <grin>:
"...how many of you succeed in building a solution in the time they expect and plan to do ?"
I do, 90%. BUT... It is my *thorough* estimates are highly accurate with respect to *my* understanding of the application. Quick & dirty "free" estimates are rarely on target. And "my" understanding of the application (or problem) isn't what counts - what counts is the _user's_ perception of how well my solution solves the _actual_ problem. That's why extensive analysis is so important!
My car is making an odd noise and I need to get it into the shop. I'm well aware that it's nearly impossible for me to call the garage and explain the problem and get an accurate estimate of what it'll cost to fix it. The best I'll probably get is "well, it could be this, this, or this..." If I take it in a let them listen to it, they'll have an even better idea of what's wrong. But ultimately it's when I let them put the car up on the rack and have a look around that they'll do the best job of diagnosing the problem. And even if I choose not to have them fix it, I'll probably owe some $$ for the diagnosis. Is it worth it? If I get the correct diagnosis for the problem, absolutely! What if I choose to rely on an ever-the-phone guess about what's wrong and pay nothing? Then I take the car in to have the work done and the problem is far more serious (read: expensive) than I was led to believe. Will I be upset with the bill? Absolutely!
Gee, now that I think about it, I'm probably "preaching to the choir." The audience I really need is my current and future clients! That's why some of the commentary in here may well end up on my website some day! (When I get around to creating one, that is. <chuckle>)
ASKER
Can see you had a good weekend, fully loaded !
Yes, I know the user that doesn't know what he wants, I even find it hard myself to specify my needs on the forehand!
That's why I'm more and more coming to the time-boxing approach. Start with a rough but working application for only the main functionality. Then the user can try howit "fits" and can develop new thoughts about newer builds.
The main essence on "our" side is that our code is as easy to change as we like, as every redundancy is killing! That's the basis for my interest in repositories. They just contain my meta-data and can be used to generate (static repository) or operate (dynamic repository) a working system.
I've been working with both types of tools and I'm mad about the dynamic one, but it's development was stopped!
It's also why I started at looking at VB for it's repository, but I still have to start looking into it, E-E is getting too much time. (Like your web-site believer?)
Nico
Yes, I know the user that doesn't know what he wants, I even find it hard myself to specify my needs on the forehand!
That's why I'm more and more coming to the time-boxing approach. Start with a rough but working application for only the main functionality. Then the user can try howit "fits" and can develop new thoughts about newer builds.
The main essence on "our" side is that our code is as easy to change as we like, as every redundancy is killing! That's the basis for my interest in repositories. They just contain my meta-data and can be used to generate (static repository) or operate (dynamic repository) a working system.
I've been working with both types of tools and I'm mad about the dynamic one, but it's development was stopped!
It's also why I started at looking at VB for it's repository, but I still have to start looking into it, E-E is getting too much time. (Like your web-site believer?)
Nico
Yeah, isn't that site really cool?! (Wise guy)
Yup, EE's getting too much of my time, too. Thus the brief answers you see here!
I like what LJG had to say about RAD development:
"Once I go through the process, I do not go back to the client in the middle of the process unless I have a question. I do not want them to change the bid until I get it installed."
Well, I like it in theory anyway! I can't imagine disappearing for a long time and then coming back with, "Okay, here's what I did! In my view, it's *done*... want changes? That's another phase..." Yes, I am over-simplifying it. In LJG's case, he does a *lot* more up-front work than I do. But I've had enough trouble convincing clients to pay for the scope/design phase without increasing that cost. People don't like paying for something that doesn't give tangible results. I can't blame them, either. Free quoting is a standard part of a lot of businesses (like auto repair, insurance work, etc.). Unfortunately, it doesn't fit well with our line of work. The architect/building scenario is an excellent way of putting it! Where was I...?
Yup, EE's getting too much of my time, too. Thus the brief answers you see here!
I like what LJG had to say about RAD development:
"Once I go through the process, I do not go back to the client in the middle of the process unless I have a question. I do not want them to change the bid until I get it installed."
Well, I like it in theory anyway! I can't imagine disappearing for a long time and then coming back with, "Okay, here's what I did! In my view, it's *done*... want changes? That's another phase..." Yes, I am over-simplifying it. In LJG's case, he does a *lot* more up-front work than I do. But I've had enough trouble convincing clients to pay for the scope/design phase without increasing that cost. People don't like paying for something that doesn't give tangible results. I can't blame them, either. Free quoting is a standard part of a lot of businesses (like auto repair, insurance work, etc.). Unfortunately, it doesn't fit well with our line of work. The architect/building scenario is an excellent way of putting it! Where was I...?
ASKER
Hi all,
Thanks all for the contributions!
I like discussing the way systems are developped, as I think that's the way to discover your own strong and week points, thus giving the possibility to change and improve!
I'll close the question within 3 day's and only have the problem how to divide the points. (Any suggestions?)
Thanks again for the tremendous amount of time invested and the visions shared!
So one concluding motto:
"To share knowledge is no division but multiplication!"
Nic;o)
Thanks all for the contributions!
I like discussing the way systems are developped, as I think that's the way to discover your own strong and week points, thus giving the possibility to change and improve!
I'll close the question within 3 day's and only have the problem how to divide the points. (Any suggestions?)
Thanks again for the tremendous amount of time invested and the visions shared!
So one concluding motto:
"To share knowledge is no division but multiplication!"
Nic;o)
Nico
The points are not important to me. The discussion is what I'm interented in.
So no need to include me in the group to give the points to. I appreciate the discussion and information.
Larry
The points are not important to me. The discussion is what I'm interented in.
So no need to include me in the group to give the points to. I appreciate the discussion and information.
Larry
I'd humbly turn down any offer to receive points... EXCEPT for the fact that we're competing!!!! LOL!
BTW: Congrats on whupping me... looks like I'll be eating your dust from now on <g>
BTW: Congrats on whupping me... looks like I'll be eating your dust from now on <g>
ASKER
Well, you made it into a competition, remember! ;-)
But in the near future I'll have to spend less time here and more to study for my Master of Science degree.
So you'll get your turn.!
Just let us whipe out those "silent 60-ies" !
Nic;0)
But in the near future I'll have to spend less time here and more to study for my Master of Science degree.
So you'll get your turn.!
Just let us whipe out those "silent 60-ies" !
Nic;0)
Gee, the competition between us is killing _both_ of us, huh? Unfortunately it has spurred me on to be involved here more than I should. Like I've said before, EE doesn't pay the bills! (Well, except for one person who I helped that may have "real" work for me...)
First it was "get to 50 K" then "Get on the top 15!" now, "Get to 60K!" What next? 100K isn't too far away...
Like you, I plan to back off here very shortly, too. In the mean time,
Wipe out the "Silent 60-ies"
is our war cry!
First it was "get to 50 K" then "Get on the top 15!" now, "Get to 60K!" What next? 100K isn't too far away...
Like you, I plan to back off here very shortly, too. In the mean time,
Wipe out the "Silent 60-ies"
is our war cry!
I have just started reading a book, "Doing Objects in Microsoft Visual Basic 5.0," by Deborah Kurata, (the v5.0 book was less expensive than the v6 book by ~ 4:1...).
I am on page 39, and already have learned a great deal about how to approach project inception and development. She presents an exceptionally cogent way of approaching the process, with an acronym, "GUIDS", (pronounced ‘Guides’), which stands for the phases of development:
• Goal-Centered Design
• User Interface Design
• Implementation-Centered Design
• Data Design
• Strategies For Construction
In the Goal-Centered Design phase you are finding out what the business rules are, how the parts of the scope interact, (eg, how the sales department interacts with a price-quote request), and so on.
In that arena, you are preventing the user from telling you how many buttons go on the toolbars, what color to make the backgrounds of the forms, etc.
This is a big step in itself; you get the company managers to speak to you in thier language, instead of trying to get them to speak yours. Afterall, we are the software/application developers, they aren't!
When you get to the design of the user interface you are asking how the application will be pressed into service. But you already know what is it going to do, so this phase is smoother than one would think, plus the discussion is less on specific appearance, and more on utilization.
With just those two phases 'under your belt,' and nothing more, you would be MUCH more qualified to participate in the discussion of appearance, (should the topic come up), because you have a much clearer understanding of the target and use.
Another aspect of the book, it focuses much on the why of object-oriented design. From what I've read thus far, I am thinking that all of us could have easier lives if we would become more familiar with the philosophy of object orientation, and would press those ideas into service in the design of our applications.
(Just a good-morning! note...)
As an aside: Heidi recently turned 5 months old, and is a riot! She is generally in a good mood, is very talkative, (like her dad...), and makes me laugh all the time.
Brian
I am on page 39, and already have learned a great deal about how to approach project inception and development. She presents an exceptionally cogent way of approaching the process, with an acronym, "GUIDS", (pronounced ‘Guides’), which stands for the phases of development:
• Goal-Centered Design
• User Interface Design
• Implementation-Centered Design
• Data Design
• Strategies For Construction
In the Goal-Centered Design phase you are finding out what the business rules are, how the parts of the scope interact, (eg, how the sales department interacts with a price-quote request), and so on.
In that arena, you are preventing the user from telling you how many buttons go on the toolbars, what color to make the backgrounds of the forms, etc.
This is a big step in itself; you get the company managers to speak to you in thier language, instead of trying to get them to speak yours. Afterall, we are the software/application developers, they aren't!
When you get to the design of the user interface you are asking how the application will be pressed into service. But you already know what is it going to do, so this phase is smoother than one would think, plus the discussion is less on specific appearance, and more on utilization.
With just those two phases 'under your belt,' and nothing more, you would be MUCH more qualified to participate in the discussion of appearance, (should the topic come up), because you have a much clearer understanding of the target and use.
Another aspect of the book, it focuses much on the why of object-oriented design. From what I've read thus far, I am thinking that all of us could have easier lives if we would become more familiar with the philosophy of object orientation, and would press those ideas into service in the design of our applications.
(Just a good-morning! note...)
As an aside: Heidi recently turned 5 months old, and is a riot! She is generally in a good mood, is very talkative, (like her dad...), and makes me laugh all the time.
Brian
Interesting. Guess I'll have to add it to my reading list. (which means I may get around to it in a couple years LOL!)
When I was still an _employee_ (vs a business owner), I had started studying for MS certification and chose to begin with "70-100: Analyzing Requirements and Defining Solution Architectures". As it turns out, it had a lot to do with this area: Porject planning. Don't remember the name of the company who's (huge!) book I was reading, but it was very good too. A lot of practical information, not just technical and theoretical. If anyone's interested, I can hunt down the title, publisher, etc. I do know it was part of an overall training series.
P.S. Thanks for the update on your daughter... it's nice to keep in touch with the people behind the "handles"!
When I was still an _employee_ (vs a business owner), I had started studying for MS certification and chose to begin with "70-100: Analyzing Requirements and Defining Solution Architectures". As it turns out, it had a lot to do with this area: Porject planning. Don't remember the name of the company who's (huge!) book I was reading, but it was very good too. A lot of practical information, not just technical and theoretical. If anyone's interested, I can hunt down the title, publisher, etc. I do know it was part of an overall training series.
P.S. Thanks for the update on your daughter... it's nice to keep in touch with the people behind the "handles"!
ASKER
Hi Brian,
If you're interested in OO, I can also recommend 'Object Technology' A Manager's Guide by David A. Taylor
See: http://cseng.aw.com/bookdetail.qry?ISBN=0-201-30994-7&ptype=0
For the desing and project management side the book: Objects, Components and frameworks with UML (The catalysis approach) from D'Souza and Wills can also be recommended.
See: http://cseng.aw.com/bookpage.taf?ISBN=0-201-31012-0&ptype=0
And don't forget between all of this to enjoy your daughter, as they grow real fast as I found out.
I'm now struggeling with my two daugthers for the computer to do some EE stuff while they want to chat, chat, chat and with my son as he wants to run Napster and burn CD's !
Nic;o)
If you're interested in OO, I can also recommend 'Object Technology' A Manager's Guide by David A. Taylor
See: http://cseng.aw.com/bookdetail.qry?ISBN=0-201-30994-7&ptype=0
For the desing and project management side the book: Objects, Components and frameworks with UML (The catalysis approach) from D'Souza and Wills can also be recommended.
See: http://cseng.aw.com/bookpage.taf?ISBN=0-201-31012-0&ptype=0
And don't forget between all of this to enjoy your daughter, as they grow real fast as I found out.
I'm now struggeling with my two daugthers for the computer to do some EE stuff while they want to chat, chat, chat and with my son as he wants to run Napster and burn CD's !
Nic;o)
Given what I have learned from this book so far, it would appear that if OO is available, there is never a reason to NOT use it.
What is UML?
I will enjoy my dughter a lot more when she can talk. I get more fun out of talking to kids!
I was at a restaurant with friends and their ~ 4-year old daughter. She was having so much fun with me that she decided to get up from the other side of the table, and come araound to my side. Then she asked me to get her plate for her from the other side of the table. That's when the fun began.
I reached across easily, got the plate, held on _tight_, almost set it down on the table, stopping about 3" above the table top and told her it was 'stuck!'
I pushed on it with one hand, (resisting back equally with the other), showing that it wouldn't move. She tried pushing on it, (which I equally resisted against), confirming that it was stuck in space...
I love doing outlandish stuff like that with kids, but language is intrinsic to that kind of activity.
Brian
What is UML?
I will enjoy my dughter a lot more when she can talk. I get more fun out of talking to kids!
I was at a restaurant with friends and their ~ 4-year old daughter. She was having so much fun with me that she decided to get up from the other side of the table, and come araound to my side. Then she asked me to get her plate for her from the other side of the table. That's when the fun began.
I reached across easily, got the plate, held on _tight_, almost set it down on the table, stopping about 3" above the table top and told her it was 'stuck!'
I pushed on it with one hand, (resisting back equally with the other), showing that it wouldn't move. She tried pushing on it, (which I equally resisted against), confirming that it was stuck in space...
I love doing outlandish stuff like that with kids, but language is intrinsic to that kind of activity.
Brian
UML: Universal Markup Language. From the little I know about it, it's a standardized way of drawing relationship diagrams. Now you know about all I do about it! :)
ASKER
Nearly right believer, it's *Unified* Markup Language and UML is the abbreviation that's used in most publications.
As the Object Orientation started from the "programming" level, it has taken some time before there was a modelling method to describe (how to develop) a system. UML starts with the specification of Use Cases and that's just a description from the user's point of view of the wat and how of the system. That's the way I think you should work. Brian also stated that it's important to ask the user for his needs and to discuss this in the user's "language".
Too often I've seen collegues trying to discuss a datamodel with their customers, that really doesn't work (discussing normalized tables is in fact the same).
I used the datamodel to verify or I could extract the data for the forms and reports and whether I covered all relations (1:1, 1:n and/or n:m). A datamodel is a great way to verify if you've got all info needed. But I tend to call it an experts model and wouldn't show it to a user.
I think UML has the possibility to grow to a more or less standard on OO-design.
Brian, I know it's fun to tease little kids.
Once my son came home from primary school telling that they had a fish in their class. So I asked "A paper fish?" His answer: "No" Then I asked "From plastic" His answer: "No" Then I asked "From wood" His annoyed answer: No, a real one, one that you can KILL !
My daughter once came with a surprising question for us: "When did they invented color?"
It took us a while to discover the background.......
It was a real good question as prooved her explanation: All old photograhps were in black and white and also the old movies were black and white so if you're not aware that it's a 'shortcoming' from technology, you could conclude that in the old days everything really was black and white!
Nic;o)
As the Object Orientation started from the "programming" level, it has taken some time before there was a modelling method to describe (how to develop) a system. UML starts with the specification of Use Cases and that's just a description from the user's point of view of the wat and how of the system. That's the way I think you should work. Brian also stated that it's important to ask the user for his needs and to discuss this in the user's "language".
Too often I've seen collegues trying to discuss a datamodel with their customers, that really doesn't work (discussing normalized tables is in fact the same).
I used the datamodel to verify or I could extract the data for the forms and reports and whether I covered all relations (1:1, 1:n and/or n:m). A datamodel is a great way to verify if you've got all info needed. But I tend to call it an experts model and wouldn't show it to a user.
I think UML has the possibility to grow to a more or less standard on OO-design.
Brian, I know it's fun to tease little kids.
Once my son came home from primary school telling that they had a fish in their class. So I asked "A paper fish?" His answer: "No" Then I asked "From plastic" His answer: "No" Then I asked "From wood" His annoyed answer: No, a real one, one that you can KILL !
My daughter once came with a surprising question for us: "When did they invented color?"
It took us a while to discover the background.......
It was a real good question as prooved her explanation: All old photograhps were in black and white and also the old movies were black and white so if you're not aware that it's a 'shortcoming' from technology, you could conclude that in the old days everything really was black and white!
Nic;o)
I'm a little late in the conversation and I will not try to rephrase or repeat what has been said. But let me take the custom home analogy a little further. I have built a custom home and believe me, it is not a cut and dry as it has been mentioned.
First, the architect will draw up some rough sketches (for a fee) related to overall look and feel. One the look is basically decided on, the architect will have to work with land/soils/structural engineers to be sure that the design he has in mind can be made to work with the parcel. The the soils engineer will have to go to the local building department with the footprint of the house and the lay of the land to verify that this meets code and has taken into consideration water runoff, erosion, environmental damage, tree removal, etc.
When this is verified the various engineers will get together and calculate the structurial formulas for the architect's initial design. At this point in time, the group will confir with the home owner to determine if they are willing to spend the extra costs involved with soil and structural stability or want to change the house design to alleviate some of the problems (and there will almost always be unknown problems).
After a lot more back and forth and submissions and approvals from every department in your local government (12 to 15 depending on the size of the city), you may have a basic design. A builder can give you an estimate (no one will work on a fixed price in the custom building business) to build your new home. BTW, this is all supposing that you first found and secured (purchased) the piece of property to build the house upon.
While the builder is starting on the foundation, you will be business with other design people as well as the architect. Lighting designers to establish how many lighting fixtures and where. When you get through, you will have another set of blue prints just for the lighting layout.
Next comes the interior designers. They will work with you to determine the type of appliances you want in the kitchen and the types of fixtures that you want in the kitchens and bathrooms. This is another set of blue prints.
You need a heating contractor to help determine the layouts of the heating/cooling and the venting for all the fixtures. Another set of blue prints.
These drawings drawings go to the electrical contractor for another set of blue prints for all the wiring in the house. This also covers phone, TV cable, computer cable, intercom, security, etc.
The plumbing contractor will draw up a set of blue prints for all of the water and soil pipes to connect all the kitchen and bath fixtures.
None of these drawings are free and none of them can really be done until you complete the step ahead of them.
One or more of these designers/contractors may help you out with picking out and buying the exact fixtures, cabinets, etc. that you want or you might have to head for the cabinet shop, plumbing supply house, lighting supply house, and more on your own.
You still only have an estimate of what this is going to cost but no total price yet. (The banker is pulling his hair out every time you go in with a new bid. He has to verify that each bid is in line with your credit worth and the quality of the house, the bank figured that you would be able to afford. The banker makes periodic payments to the various contractors and holds out a percentage of the cost of each job until that particular work is completed, inspected, and approved by everyone.)
In the meantime, various economic and evironmental crisises around the world cause the prices of material and labor to shift all over the place.
There is much more to go through - flooring, painting, landscaping, pool builders, etc. And I can guarantee you one thing... every contractor will contact you daily for decisions on items that could not be firmed during the design phases. They will not be code critical situations but they all will require you to pay more money to the contractor than you thought you would have to pay. A rule of thumb - take whatever estimate any contractor gives you and double it. If it comes out less, you have a very great contractor and are very lucky.
We go though the same types of problems when we attempt to bid on a computer contract of any type. Things will change. It will take longer than every one thought. It will cost more than anyone thought. If we as consultants and computer contractors could work like builders, we'd be a lot richer and a lot happier.
Jim
First, the architect will draw up some rough sketches (for a fee) related to overall look and feel. One the look is basically decided on, the architect will have to work with land/soils/structural engineers to be sure that the design he has in mind can be made to work with the parcel. The the soils engineer will have to go to the local building department with the footprint of the house and the lay of the land to verify that this meets code and has taken into consideration water runoff, erosion, environmental damage, tree removal, etc.
When this is verified the various engineers will get together and calculate the structurial formulas for the architect's initial design. At this point in time, the group will confir with the home owner to determine if they are willing to spend the extra costs involved with soil and structural stability or want to change the house design to alleviate some of the problems (and there will almost always be unknown problems).
After a lot more back and forth and submissions and approvals from every department in your local government (12 to 15 depending on the size of the city), you may have a basic design. A builder can give you an estimate (no one will work on a fixed price in the custom building business) to build your new home. BTW, this is all supposing that you first found and secured (purchased) the piece of property to build the house upon.
While the builder is starting on the foundation, you will be business with other design people as well as the architect. Lighting designers to establish how many lighting fixtures and where. When you get through, you will have another set of blue prints just for the lighting layout.
Next comes the interior designers. They will work with you to determine the type of appliances you want in the kitchen and the types of fixtures that you want in the kitchens and bathrooms. This is another set of blue prints.
You need a heating contractor to help determine the layouts of the heating/cooling and the venting for all the fixtures. Another set of blue prints.
These drawings drawings go to the electrical contractor for another set of blue prints for all the wiring in the house. This also covers phone, TV cable, computer cable, intercom, security, etc.
The plumbing contractor will draw up a set of blue prints for all of the water and soil pipes to connect all the kitchen and bath fixtures.
None of these drawings are free and none of them can really be done until you complete the step ahead of them.
One or more of these designers/contractors may help you out with picking out and buying the exact fixtures, cabinets, etc. that you want or you might have to head for the cabinet shop, plumbing supply house, lighting supply house, and more on your own.
You still only have an estimate of what this is going to cost but no total price yet. (The banker is pulling his hair out every time you go in with a new bid. He has to verify that each bid is in line with your credit worth and the quality of the house, the bank figured that you would be able to afford. The banker makes periodic payments to the various contractors and holds out a percentage of the cost of each job until that particular work is completed, inspected, and approved by everyone.)
In the meantime, various economic and evironmental crisises around the world cause the prices of material and labor to shift all over the place.
There is much more to go through - flooring, painting, landscaping, pool builders, etc. And I can guarantee you one thing... every contractor will contact you daily for decisions on items that could not be firmed during the design phases. They will not be code critical situations but they all will require you to pay more money to the contractor than you thought you would have to pay. A rule of thumb - take whatever estimate any contractor gives you and double it. If it comes out less, you have a very great contractor and are very lucky.
We go though the same types of problems when we attempt to bid on a computer contract of any type. Things will change. It will take longer than every one thought. It will cost more than anyone thought. If we as consultants and computer contractors could work like builders, we'd be a lot richer and a lot happier.
Jim
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hello everyone,
I am reducing the points to zero and moving this question to the PAQ so that it is freely viewable by anyone interested.
Nico - You can create new questions for each of the Experts (8 as I think) to award about 10 points each using this link (right click and open in new window):
https://www.experts-exchange.com/bin/NewQForm?ta=91
A good title for the questions will be 'For ExpertName -- 10447918' with the appropriate Expert name inserted. That will show who it is for and what question it is for at a glance.
Be sure to come back and let the Experts know once you have created the new questions.
darinw
Customer Service
I am reducing the points to zero and moving this question to the PAQ so that it is freely viewable by anyone interested.
Nico - You can create new questions for each of the Experts (8 as I think) to award about 10 points each using this link (right click and open in new window):
https://www.experts-exchange.com/bin/NewQForm?ta=91
A good title for the questions will be 'For ExpertName -- 10447918' with the appropriate Expert name inserted. That will show who it is for and what question it is for at a glance.
Be sure to come back and let the Experts know once you have created the new questions.
darinw
Customer Service
ASKER
Please all check access for some points as a token of gratitude for participation !
Nic:o)
Nic:o)
ASKER
markcrandell,
jjjjjjjj and
Jim Morgan,
Please check my open questions in my profile !
Nic;o)
jjjjjjjj and
Jim Morgan,
Please check my open questions in my profile !
Nic;o)
Brian