Principals of Software Development

Do not lie to, or mislead anyone, that uses or depends on the software you are building. Label all things correctly.

Shortcuts only save time, today, by pushing away the issues into the future. If too many issues all come due at the same time, the project explodes.

For interfaces, try not to stand out. Software that fits into its surroundings is often preferred.

Users are the experts at describing the parts of their own problems, software developers should be the experts at providing software solutions to these problems.

Make things relative instead of absolute. Make things explicit instead of implicit. Yes, it is a contradiction.

Assume the worst. If it can fail, sooner or later it will fail.

Don’t worry about management. They’ll eventually get fired one day, it’s your peers that you need to impress.

Shortcuts are the road to hell. If you can, try to do it correctly, you won’t regret it.

Don’t take potential users ‘literally’. If they could concisely express their issues they’d probably quit their jobs and start building software instead.

Don’t assume. Details are rarely obvious or intuitive. You can leverage some of your past, similar, experiences, but only if they are relevant. Otherwise, you have to ask.

If you ask the right question, you’ll get the right answer. Consider your questions very carefully, some answers can waste a lot of time or lead you astray.

Control people’s expectations. They don’t automatically understand what is happening and are often prone to making their own invalid assumptions. Make sure they really understand the issues first.

It’s very easy to throw together huge lists of instructions for a computer to follow. It is very hard to keep it all organized, stable, and to leverage your earlier efforts. If you master that, then you can build sophisticated stuff.

Some computations are easy to understand. Some require a massive amount of deep, complex, and sometimes rare knowledge. Learning to distinguish between them saves a lot of wasted effort.

Code may work, but can still be weak. Weak code will break, just not today. Strong code always works, no matter what happens.

Working code is a good start, but it isn’t complete until it has been cleaned up, documented and properly handles every possible error.

People don’t need more code, they need solutions that really solve their problems.

All code written by anyone has a huge number of bugs. They don’t go away on their own, effort needs to be spent to find and then correct them. There are many, many different ways to find bugs, pick carefully. Testing is only successful if it finds the bugs that exist.