Best software practices: development process
Autor: Damian Chodorek • Opublikowany: 23 lutego 2019 • Ostatnia aktualizacja: 27 marca 2020 • Kategoria: Good practices
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?