Your productivity in db developing (1 Viewer)

[Boro]

Could you write, if you are developer of db in Access
1. is it ordered project by someone or you set out the project
2. how many tables
3. how many ?
4. how many forms
5. reports
6. lines of code approx.
7. how many working hours approx?


For my project
1. I set it out
2, 10 tables
3. 5 ?
4. 6 forms
5. 4 reports
6. 100 lines of code approx
7. 1000 working hours

 

[boblarson]

What is the purpose of this? You can't define how many tables, forms, reports, lines of code like that. Of course you can ESTIMATE, but until you have all technical specifications drawn up, you will not know the number of tables. And, you will not know the number of anything else.

So, what is the purpose of your question? It and some of your other questions seem a little strange to me and I'm wondering what your ultimate goal is.

 

[Boro]

@Bob Just for estimation, as Your write. And just for those who want to write it.

 

[boblarson]

@Bob Just for estimation, as Your write. And just for those who want to write it.

My answer is that a good developer cannot answer that question until tech specs are developed.

 

[Boro]

@ Bob Ok. Maby, the topic of thread is not good and I agree that we could not see the productivity of developer from that but think that parametars are interesting for some conclusions.

 

[Banana]

I have to agree with Bob on this.

I don't even bother with tables & queries until I've talked to the client or the project manager about the specs and requirements. It's theoretically valid to have a database with only one table and one query, zero lines of code and it's also valid to have a database with 100 tables with 1000 queries and 10,000 lines of code, but the real dependency is on the tech specs and what clients actually need to make the database work as they need it.

It's also possible to have a database with 100 tables and 1000 queries and have zero lines of code, which should illustrate that lot will depend on the specific functionality desired by the client.

 

[music_al]

I agree with Bob. Im a Business Analyst and giving an accurate estimate is like trying to nail jelly to a wall...

What might seem a small project to the Customer can quickly grow into a complex project that requires some complicated code and clever queries (which I think you referred to as ?).

I would say its best to estimate high if youre forced to give an estimate.

 

[Banana]

I would say its best to estimate high if youre forced to give an estimate.

Well, IMHO, if a client actually demanded an estimate without a tech specifications, I'd have to tell them straight up that they need to have one before any estimate could be had. Estimating high may seem to be playing it safe but in long run, I think it'll hurt the relationship.

It's kind like asking a mechanic to estimate the labor & costs for fixing a car that he hasn't even looked at. It's common for mechanic to charge a diagnostic fee to determine the estimate (though there are certainly shops that does free estimating, but you still have to take the car to them!)

 

[gemma-the-husky]

having said that, once you are famiilar with dbs development, and have an arsenal of ready developed tools - then with experience, you will be able to guesstimate reasonably accurately how long a prohject will take - be that 2-3 days, a week etc etc

its more to do with understanding what the app is for though, rather than trhe number of objects - becuase that will most likely change when you start developing.