Productive best practices are about developing efficient, collaborative behaviors, not about micro-managing activities. Minimal requirements give great people the freedom to do great work. The work will never be great if you force everyone down the path of the least common denominator.
- Compartmentalizing stops the thrill of stress and failure.
The big-brained developer who loves to keep a dozen balls in the air at once is no smarter than the organized developer who can handle fifty? Divide and conquer.
- Force yourself to care about security today, not tomorrow.
To say something will probably never happen just means you want to wait until it blows up to deal with it, and by then it's too late. Consider the consequences and act appropriately
- Don't take risks and give away the rewards.
If your costs don’t include testing, security checks, load balancing, backups, redundancy, etc. you have to explain that upfront. Otherwise your client benefits from the lower cost, but still blames you for the crash.
- Develop for the next developer.
Developing a project is the first step. Managing its life-cycle is much bigger. If you develop a house-of-cards, no matter how pretty it is, turn and run.
- Don't add anything to your best practices that you are not serious about.
When the list gets too long to memorize, it is too long to review. Move it from your virtual trash (where you just ignore it) to the physical trash.
- Expect clients to know very little about what they want. Expect the client’s users to know way less.
It will never be the client’s fault when it does not work, or that it is too complicated for the user. Every client knows that. If you accept it upfront and take on the responsibility, you will too.
- Everyone is responsible for quality.
You may know your part works fine, but it will end up in the trash bolted to the parts you didn't think would affect you.
- Everyone develops iteratively, one pinch at a time.
No one ever sees the whole project from the beginning. Allowing time for change makes it easier to accept. The converse does not prevent it.
- The cost of a project includes both bugging and debugging.
Everyone makes mistakes. Plan as many hours on QA as development. Going live without debugging is just denial and will be more difficult to charge.
Open Up Feed