Best software practices: development process

Best practices regarding development process. Gathered from various sources.

• Rather than trying to find extraordinary people to do a job, design the job so that ordinary people can do it well.
• Start small, then extend.
• Everything takes longer than you think.
• Complexity and technology investment is a function of time, so we should revisit theese decision periodically.
• Deployment/monitoring/testing/analysis is first class consideration.
• Whatever the problem is, there’s always a right way to solve it.
• It is more important to reduce the Effort of Maintenance than it is to reduce the Effort of Implementation.
• The only time you should seriously consider ditching backwards-compatibility is when keeping it is preventing you from adding obviously useful and important new features.
• The way to measure the productivity of a developer is to measure the product that they produce.
• Your first goal is to get the system into a place where it’s getting better over time, instead of getting worse.
• The best way to get real security in things is simplicity.
• Make features easy to use; don’t make them unnecessary flexible.
• Humans should dominate machines, business logic should dominate systems.
• All you have to do to succeed in software is to consistently suck less with every release.
• If you’re not sure how to write even that core code yet, then just start with the code you are sure about.
• When you’re truly clever, what will show up for users is that your program is awesome. It’s so awesome, the user hardly notices it’s there. That is true brilliance.
• The desirability of a change is directly proportional to the value now plus the future value, and inversely proportional to the effort of implementation plus the effort of maintenance.
• The quality level of your design should be proportional to the length of future time in which your system will continue to help people.
• The longer your program exists, the more probable it is that any piece of it will have to change.
• You can determine whether or not a technology is “bad” by looking at its survival potential, interoperability, and attention to quality.
• The difference between a bad programmer and a good programmer is understanding.
• Its harder to build great team than a great project. Make your team squad independent of projects.
• All non-trivial abstractions, to some degree, are leaky. Abstractions save us time working, but they don’t save us time learning.
• Roles and responsibilities issue is often a relationship issue. What really is the source of the friction?