Previously, I've talked about what I consider to be the first two rules of software development:

The first rule was simple "Don't Trust the Users" and seems to have been pretty well unanimous from around the community, especially from security folks.  My second rule - "Consistency" - was a little less clear but tends to focus on doing the same thing the same way every time... until you learn a better way.  It doesn't matter whether it's Coding Standards, security, etc. Doing it the same way helps people understand.  Which

I've struggled with the best way to present this point and have just decided to say it.

The Third Rule of Software Development is:

Someone is probably smarter.

Almost every day, someone passes me a link to a study or article worth a chuckle and then gets prompty filed away or deleted.  It's not that the thought it unwanted or unappreciated, just that they often don't elicit further thought.  Late last week, I received a link that was just the opposite.

Dennis McDonald - a Northern Virginia local that I've talked with a number of times - has released the preliminary findings of his study entitled "Blogging and Project Management".  Both as a long-time blogger and as someone building and working with Project Management tools (*cough*web2Project*cough), I found his initial discoveries useful.  Some of the findings were what you'd expect but some of the questions and comments that popped out at me were interesting:

• It appears that Project Managers are mostly unaware of blogging.  Is it simply ignorance and lack of exposure or has there been a conscious decision to exlcude it from consideration or has it been determined to be unsuitable?
• In their "replacing email" points, are they wanting to document discussions (dynamic, like a forum) or the decisions made (static, even if changed later)?  It seems like each of these would encourage/necessitate different tools and mindsets... neither of these seem appropriate for a blog.
• While I have yet to interact with a single organization that is doing wholly internal blogging, I've find high acceptance of Wikis within a number of organizations and have helped them develop "wiki best practices".  Do organizations see these as mutually exclusive tools/concepts?
• In the Open Source world - a skewed sample, no doubt - the acceptance of blogging/wikis/etc has been high and the creative application of the tools has been amazing.  I wish more companies would look at Open Source - not just to use - but to learn and review best practices from.  I think there's a huge amount of experience, knowledge, and mistakes that can be learned from.

Yes, I've already sent these to Dennis, maybe he'll have/gain insight to share with the rest of us.  I look forward to the full report.  In the meantime, the preliminary findings are available.

One of the single best things and single worst things about PHP is the PHP Manual.

It's complete, is always up to date, specifies when commands became available, and has a huge amount of commentary and tips spanning the past few years. Quite often I get more from the comments than the actual entry... There are parts of the Manual that I use far more than any others... like the formatting parameters that date() takes. I remember the basics, but it seems that I almost never use the basics. I use this page so much that it's always in my browser history and I've considered adding it to my toolbar.

Unforutnately, the downside is that unless you know the keywords or related topics that you're looking for, you don't have a chance of finding it. The onsite search is sufficient for exact/partial terms but mediocre at best for anything close. A long time ago, I gave up and relied on Google for that heavy lifting.

Well, due to the brave efforts of one of the DCPHP'ers - Jason Lefkowitz - we have an alternative in MyPHPDocs.com. The site lets you click and drag the portions of the manual that are the most important to you, hit a button, and voila. You have your own manual. The best thing is that the tool isn't copying content from the site. You don't have to worry about getting out of date because it effectively acts as a page of bookmarks to the core manual.

I believe that part of what defines a person is what they do when they fail or make mistakes. This goes for personal mistakes and systemic problems. Everybody makes some mistakes, but what do they do when they realize it?

I recently received an email from a friend who was excited about an upcoming interview. We talked about the company a bit and it sounded interesting. Then he went to the interview and took some notes on how they meet the criteria of the Joel Test and they got a miserable 4.