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?

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.