Josh Rules (for business people)
The list of tips from a database expert and development team member Josh Berkus, in my opinion, can be useful not only to database consultants. These tips are related to customer relations. Some recommendations, it seems to me, are relevant for freelance developers.
Josh Berkus has been a member of the core PostgreSQL development team (PostgreSQL Core Team) since 2002. He is currently working for Sun Microsystems, joining an open DBMS group. Prior to working on PostgreSQL, he worked with various other applications and technologies, including OpenOffice.org, Microsoft SQL Server, Oracle PL / SQL, and (oh, horror!) COM +.
I spent eight years working as a database consultant. Since at the moment I am something else and I can soon forget everything, I think we should write down some useful lessons that I learned during this time.
')
1. The state of the data reflects the state of the business. Show me a client with chronic problems in the database - and I will show you a client with chronic management problems.
2. Three things you will never encounter:
3. Decisions made in relation to the database “live” for a very long time (“there is nothing more permanent than temporary”): the average lifetime of a “temporary, one-time” database application is 4 years. Some of these pieces of code date back to the 1960s and still work today. So immediately rely on long-term use.
4. Bad customers will destroy your business: the ability to recognize a bad customer in time and refuse it or terminate a contract in time is half the success. Get ready to run away any minute.
5. Do not ask what else you can do: it’s not what you can do, but how much the customer is willing to pay for it and how long it is ready to wait.
6. The relationship between time and money is logarithmic. That is, if you want to reduce the time by 20%, then the budget will double. Reducing the budget by 30% will increase development time 4 times.
7. Any estimates are too optimistic: the development of a new application will take you 3 times more than the estimated time and will be twice as expensive. Or vice versa.
8. You never:
9. All real databases contain a spoonful of tar , which is pieces of data that are difficult to attempt to use them in well-defined business processes. These "spoon of tar" are the reason for the fact that it is impossible to achieve perfect data integrity, and, moreover, they entail 40% of all problems.
10. Data integrity is an end in itself: every 1% of data integrity violations double the time spent searching for problems.
11. “Insidiousness” of data integrity: a database with 20% or more data unreliable is useless. It is so useless that it is easier to recreate it again than to try to fix it. For some applications, this threshold is even lower.
12. Always enter into a contract , even if the work is just 1 day. The contract form should be yours, not the client. And when drafting a contract, consult a lawyer. It's worth it.
13. The process of signing a contract is the “litmus paper” of the process of its implementation: If a client spends a lot of time in disputes and discussing the terms of a contract, then working with him (and even more so getting money from him) will be even more difficult. If the client insists on inserting some strange and incomprehensible clause into the contract, then he plans to use it. And if you are unable to refuse and leave - you are not able to negotiate.
14. The client has a bad memory: it does not matter what the client has signed - he will forget about it in a few days, or even hours. Any customer requirements and comments need to be documented and copies kept.
15. Never settle for a fixed payment if you have not done the exact same job at least twice.
16. You can not rely on third parties: never agree to a fixed payment or payment on the condition of “achieving complete success”, if at least some part of the project depends on the speed of the work, the completeness of the documentation and the quality of the product determined by third parties - not under your complete control. This means that there should never be fixed rates when it comes to exchanging data or correcting someone else's code.
17. A client has bad taste: never let a client choose tools, subcontractors or work environment for you. Or, in the extreme, let him pay extra for it.
18. Include in the bill all meetings with the client - or you will spend half your life on them for nothing.
19. The longer you defer refactoring, the longer it will take . Changing the circuit during operation is fatal to the project.
20. The basket is not half empty : if one client can delay the payment of money, nothing prevents to do the same for everyone at the same time. So always be prepared to live two months on your own savings.
Josh Berkus has been a member of the core PostgreSQL development team (PostgreSQL Core Team) since 2002. He is currently working for Sun Microsystems, joining an open DBMS group. Prior to working on PostgreSQL, he worked with various other applications and technologies, including OpenOffice.org, Microsoft SQL Server, Oracle PL / SQL, and (oh, horror!) COM +.
I spent eight years working as a database consultant. Since at the moment I am something else and I can soon forget everything, I think we should write down some useful lessons that I learned during this time.
')
1. The state of the data reflects the state of the business. Show me a client with chronic problems in the database - and I will show you a client with chronic management problems.
2. Three things you will never encounter:
- too soft a time frame;
- a customer who pays too fast;
- accurate and complete specification.
3. Decisions made in relation to the database “live” for a very long time (“there is nothing more permanent than temporary”): the average lifetime of a “temporary, one-time” database application is 4 years. Some of these pieces of code date back to the 1960s and still work today. So immediately rely on long-term use.
4. Bad customers will destroy your business: the ability to recognize a bad customer in time and refuse it or terminate a contract in time is half the success. Get ready to run away any minute.
5. Do not ask what else you can do: it’s not what you can do, but how much the customer is willing to pay for it and how long it is ready to wait.
6. The relationship between time and money is logarithmic. That is, if you want to reduce the time by 20%, then the budget will double. Reducing the budget by 30% will increase development time 4 times.
7. Any estimates are too optimistic: the development of a new application will take you 3 times more than the estimated time and will be twice as expensive. Or vice versa.
8. You never:
- spend too much time on specifications and prototypes;
- write too detailed documentation;
- pay too much attention to the convenience of code support.
9. All real databases contain a spoonful of tar , which is pieces of data that are difficult to attempt to use them in well-defined business processes. These "spoon of tar" are the reason for the fact that it is impossible to achieve perfect data integrity, and, moreover, they entail 40% of all problems.
10. Data integrity is an end in itself: every 1% of data integrity violations double the time spent searching for problems.
11. “Insidiousness” of data integrity: a database with 20% or more data unreliable is useless. It is so useless that it is easier to recreate it again than to try to fix it. For some applications, this threshold is even lower.
12. Always enter into a contract , even if the work is just 1 day. The contract form should be yours, not the client. And when drafting a contract, consult a lawyer. It's worth it.
13. The process of signing a contract is the “litmus paper” of the process of its implementation: If a client spends a lot of time in disputes and discussing the terms of a contract, then working with him (and even more so getting money from him) will be even more difficult. If the client insists on inserting some strange and incomprehensible clause into the contract, then he plans to use it. And if you are unable to refuse and leave - you are not able to negotiate.
14. The client has a bad memory: it does not matter what the client has signed - he will forget about it in a few days, or even hours. Any customer requirements and comments need to be documented and copies kept.
15. Never settle for a fixed payment if you have not done the exact same job at least twice.
16. You can not rely on third parties: never agree to a fixed payment or payment on the condition of “achieving complete success”, if at least some part of the project depends on the speed of the work, the completeness of the documentation and the quality of the product determined by third parties - not under your complete control. This means that there should never be fixed rates when it comes to exchanging data or correcting someone else's code.
17. A client has bad taste: never let a client choose tools, subcontractors or work environment for you. Or, in the extreme, let him pay extra for it.
18. Include in the bill all meetings with the client - or you will spend half your life on them for nothing.
19. The longer you defer refactoring, the longer it will take . Changing the circuit during operation is fatal to the project.
20. The basket is not half empty : if one client can delay the payment of money, nothing prevents to do the same for everyone at the same time. So always be prepared to live two months on your own savings.
Source: https://habr.com/ru/post/31171/
All Articles