I have been adding to this list since 1998 when I started it. Actually, principle #1 has been with me for many years before that.
Bruce's Principles of Software Development
- Until software is delivered, act as if it will always be vaporware. (This applies to hiring new employees, hiring new executives, and re-orgs as well as the release of software.)
- When referring to computer systems, the phrase “We’ll never need more _____ than _____” is always wrong. It is wrong no matter what goes in the blanks.
- Always design your containers to contain containers. For example, if you are building a feature to group users, make sure that groups can contain other groups as well as users. This is true unless you know that you’ll never need more layers of nesting than one (see principle #1).
- The projected delivery date for a project is the one date on which it is guaranteed that the project will not be delivered. (Lubetkin’s Law)
- Delete things while you know why you don’t need them. (O’Neil’s Rule)
- It should “just work”. (Fajen’s Dictum)
- There should only be a SINGLE source of truth. (The DRY principle)
While what your principles are is important (they guide your decision making), it is really important that you share your principles with those you work with. You can read my post about shared principles in software development here.
"Those are my principles. If you don't like them I have others."
- Groucho Marx
2 comments:
Huh? Where are your principles? These seem to be the principles of others.
Yup, a bunch of my principles are indeed shared with others. There's no reason why your principles need to be unique or different from those of other folks. In fact, one of the most powerful things about principles is that when they are shared they make understanding and decision making much more efficient and painless.
That said, I'm more than willing to take some credit for the ones I've listed without attribution. :-)
Post a Comment