What I Believe About Writing Software

I believe that loosely coupled, encapsulated systems are the way to go, for many reasons. I believe that they are easier to mock, easier to debug, and easier to use.
I believe that good strong interfaces make for good neighbors.
I believe in separation of concerns . Specifically, I believe in separation of content from presentation.
I believe in the SOLID principles.

I believe that programming languages have their strengths and weaknesses. Arguing which is better is like asking if a hammer is better than a trowel.
I believe that operating systems have their strengths and weaknesses. Given the right toolset, I'm as happy programming in Windows as I am in Linux or MacOS.
I believe that editors have their strengths and weaknesses. On a given day, I'll use vim, jEdit, Textmate, Eclipse and IDEA to edit files. I'm fine with all of them.
I believe that frameworks have their strengths and weaknesses. J2EE works in its context. Rails works in its context. They both suck outside their context.
I believe that design by contract, program functions and static analysis tools such as ESC/2 are going to be the next wave of programming.
I believe that weak typing is good, because it speeds rapid prototyping and code flexibility.
I believe that strong typing is good, because it limits the number of possible bugs that the programmer can generate and provides a rich abstract syntax tree that can be used by tools.

I believe that simple database constraints are a good thing. Specifically, I believe that adding NOT NULL directly to your tables is a good thing.
I believe that referential integrity can, in some cases, be a good thing. I think that used properly, they reduce the amount of bugs and bad data possible.
I believe that database transactions are a good thing. You may have concurrency bugs when you scale your app if you don't use them.
I believe that 99% of the time, a decent SQL database with transaction and constraint support (i.e. not MySQL) will serve your needs, and that NoSQL is required only in some exceptional scenarios.

I believe that designing systems using finite state machines and explicit state transition can be a good way to tightly define a system and eliminate bugs.
I believe that validating an object is good, validating a state change is better, and validating a system is best.
I believe in PMD, Checkstyle, and Findbugs. I believe in Flog, Heckle, and Saikuro.
I believe in Release It , in its entirety. I believe in fail fast. I believe in bulkheads. I believe in circuit breakers.

I believe that most of the really nasty bugs come from miscommunication between different parts of a system.
I believe that defensive programming is a good thing, because it flushes out hidden assumptions between the different parts of a system.
I believe that code is not finished until you have thought about how the system responds to invalid input and exceptions.
I believe that, on some level, unit tests, assertions, defensive programming, design by contract and validation logic are all the same thing.
I believe that that a good solid configurable logging framework is a requirement for production code.
I believe that having diagnostic logging statements in production code is a good thing.
I believe that code is not finished until you have thought about how someone else is going to have to debug it.
I believe that comments can be valuable and worthwhile when they augment and not repeat the source code.
I believe that tests are not documentation. Documentation is for a human audience first, and tests have to work first and be readable second.

I believe that some tests are inherently useless, notably when they test the underlying library code and not the system under test.
I believe that any testing done by a programmer, automated or otherwise, is inherently biased in ways that don't reflect a user.
I believe that automated tests can be useful, but they can only show you the programmer's intent. Even end to end system tests will only look for specific areas of a page.
I believe that 100% code coverage provides little advantage over 80% code coverage.
I believe that a good integration test suite is better than a great unit test suite.
I believe that there is no substitute for a good QA team.