How to model a software when the user wants to override Everything!

[prabha_friend]

This is what happened in my Dairy Software. The Design and Logic were useful only up to to providing a default value to the fields. His demands are he can override everything and Anything in the Final Delivery Form... How you people normally tackle this type of requirement. Please show me some light. Thanks.

 

[Edgar_]

You negotiate the scope of the work and tell them what can and can't be done based on their budget.

You could create something that lets them create their own tables and forms if that's what everything and anything means for you. But I suppose it's something along the lines of building a flexible system. You build those by not hardcoding things that should be dynamic or customizable. So, find out what should be dynamic or customizable first.

You provided a default value to some fields.
If those should be dynamic, that is, if they should be based on something, find out what they depend on.
If those should be customizable, that is, if the users want to change the defaults themselves, then store those defaults in a table and let your user modify them so that those values can be updated on demand, do not hardcode them in the form.

 

[prabha_friend]

You negotiate the scope of the work and tell them what can and can't be done based on their budget.

You could create something that lets them create their own tables and forms if that's what everything and anything means for you. But I suppose it's something along the lines of building a flexible system. You build those by not hardcoding things that should be dynamic or customizable. So, find out what should be dynamic or customizable first.

You provided a default value to some fields.
If those should be dynamic, that is, if they should be based on something, find out what they depend on.
If those should be customizable, that is, if the users want to change the defaults themselves, then store those defaults in a table and let your user modify them so that those values can be updated on demand, do not hardcode them in the form.

I did the same exact things only. But must have got the advancement amount from them before sitting on that work. So far haven't received any amount as Advance

 

[Pat Hartman]

You are way ahead of yourself. You don't actually know how this dairy works and that shows in your schema. You also don't know how simple order entry applications work or you would have come closer to correct in your initial design.

Stop, back up. Fix the schema. Make sure you know absolutely how this dairy works before you move on.

I'm also pretty sure, you don't understand what you need to know to estimate the total cost for the application. Your explanation post sounded like you were doing this for free. If it is a paid assignment, you are being very unprofessional by rushing int to building forms, etc before validating your model. Keep in mind that you do yourself no favors and you look really bad to the client if you have to keep modifying everything you do. Not to mention that at some point the client is going to expect you to eat the cost of your gross misunderstanding of his business.

I've been developing applications for 50+ years and I refuse to take a fixed price contract unless the client can provide detailed written specs, which none of them can. I usually commit to x hours to do a preliminary design and the client pays up front for that. We agree on how many meetings we will have during that time and how available I need him to be to answer questions. Having backup people I can talk to is extremely helpful. Then we take what I've come up with and go over my estimate of how much time it will take to complete the project. Keep in mind that time is not contiguous. I also frequently have other clients that take some amount of my time during a normal workweek so I may promise to devote 30 hours to a particular project. That lets me have a little breathing room and it also takes into consideration that I may get "stuck" or have a "creative block" and I might end up having to spend 50 hours to actually produce a 30 hour work product. You also need to come up with deliverables so you can show the client that you are making progress and make him feel good about making progress payments as you meet milestones you have agreed on.

If you want to make this your business, you need to learn better professional habits and especially to not rush into giving the client work product, especially if he isn't making the progress payments. You may show him stuff in a web meeting but he gets NO product without payments being up to date.

 

[prabha_friend]

You are way ahead of yourself. You don't actually know how this dairy works and that shows in your schema. You also don't know how simple order entry applications work or you would have come closer to correct in your initial design.

Stop, back up. Fix the schema. Make sure you know absolutely how this dairy works before you move on.

I'm also pretty sure, you don't understand what you need to know to estimate the total cost for the application. Your explanation post sounded like you were doing this for free. If it is a paid assignment, you are being very unprofessional by rushing int to building forms, etc before validating your model. Keep in mind that you do yourself no favors and you look really bad to the client if you have to keep modifying everything you do. Not to mention that at some point the client is going to expect you to eat the cost of your gross misunderstanding of his business.

I've been developing applications for 50+ years and I refuse to take a fixed price contract unless the client can provide detailed written specs, which none of them can. I usually commit to x hours to do a preliminary design and the client pays up front for that. We agree on how many meetings we will have during that time and how available I need him to be to answer questions. Having backup people I can talk to is extremely helpful. Then we take what I've come up with and go over my estimate of how much time it will take to complete the project. Keep in mind that time is not contiguous. I also frequently have other clients that take some amount of my time during a normal workweek so I may promise to devote 30 hours to a particular project. That lets me have a little breathing room and it also takes into consideration that I may get "stuck" or have a "creative block" and I might end up having to spend 50 hours to actually produce a 30 hour work product. You also need to come up with deliverables so you can show the client that you are making progress and make him feel good about making progress payments as you meet milestones you have agreed on.

If you want to make this your business, you need to learn better professional habits and especially to not rush into giving the client work product, especially if he isn't making the progress payments. You may show him stuff in a web meeting but he gets NO product without payments being up to date.

Yes Pat. I need to learn a lot and shape myself to become a professional.

 

[The_Doc_Man]

The first rule of being a contract programmer is that if the business is still running, the requirements will change. Only dead things stop changing. If you promise a finished product on a fixed price, you have to recognize that you CANNOT accept changes. But there will always be an "oh, by the way, we ALSO need x..." Which means that a fixed-price development contract is a chimera, a beast that shouldn't exist.

All contracts for development must be for an hourly rate. FURTHER, if it were me, I would absolutely assure that there was no penalty for late delivery if change orders come in within X days of the most recent delivery date. In other words, insulate yourself against someone else rocking the boat at the last minute. Oh, you can still take the contract, but you tack on extra hours for all the retrofitting and/or new design that you would have to do because of the late-added requirements.

I did that kind of contracting for 10-12 years before my Navy job. ANY "build-to-order" contract needs to specify what the customer has to give YOU in terms of specifications, requirements, available data formats, expected data volume, and if they have any preconceived notions about forms and reports, you need to know what they want there, too. The MOST IMPORTANT part of any contract like this occurs before you write the first data layout or the first line of code or the first mock-up of the form. You must decide what you need to do and honestly figure out how long that is going to take. And this is NOT a time for optimism. You DO NOT schedule yourself for 12-hour days or working 7 days a week. You have to live. As a human, you have to take care of your human needs. If you burn yourself out, you are no good to your customers OR to yourself.

It ALSO wouldn't hurt to recognize that in order to do this kind of work, you need to be able to immerse yourself in their business if you want to make a database that will be a tool for their business. Otherwise you will be unlikely to hit the target that they put out there for you. That is why our discussions often point out that Access is as dumb as a box of rocks. Only someone who KNOWS the targeted business will be able to do justice to a proper business database. Access is merely another tool - just a bit more sophisticated tool, perhaps. But it is still no more than a very intelligent hammer.

 

[Pat Hartman]

If you are going to continue with this project, you need to get back to your other thread where we were discussing details and start fixing the schema