GoogleJust read on Bruno’s blog TEN golden rules/principles that I couldn’t really agree more! From his visit to Google Zürich’s headquarters he managed to collect “TEN principles of Google Engineering/Software Development”:

  1. Single-source code repository for all Google code (G has a rather big repository, and all engineers have access to the source code)
  2. Developers can checkin fixes for any Google product (an “open-source” approach)
  3. You can build any Google product in three steps (get, configure, make)
  4. Uniform coding standards (how should code “look”) across the company
  5. Mandatory code reviews before checkin (if a developer fixes a bug in Gmail, the fix needs to be approved by the Gmail team)
  6. Pervasive unit testing (a “unit” is the smallest testable part of a program; unit testing validates that it works properly)
  7. Test run continuously, emails get sent (automatically) to developers if any failure is spotted
  8. Powerful tools that are shared companywide
  9. Rapid project-cycles, developers change projects often, and can devote 20% of their time to pursuing whatever idea/project they want (if it gets somewhere, Google will then throw some more engineers at it and turn it into a product or a feature)
  10. Peer-driven review process, flat management hierarchy

and as if this ten weren’t already some amazing good advice for anyone involved in development these days, Bruno also mentioned some other “TEN (amazingly simple) things Google has found to be true“:

  1. Focus on the USER and all else will follow.
  2. It’s best to do one thing really, really well.
  3. Fast is better than slow.
  4. Democracy on the web works.
  5. You don’t need to be at your desk to need an answer.
  6. You can make money without doing evil.
  7. There’s always more information out there.
  8. The need for information crosses all borders.
  9. You can be serious without a suit.
  10. Great just isn’t good enough.

Amazing, yet so powerful tips if you managed to put them to pratice wisely and effectively, no?