Adam Culp posted the 3rd article in his Clean Development Series this week, Dirty Code (how to spot/smell it). When you read it, you should keep in mind that he is pointing out practices which correlate with poorly written code not prescribing a list of things to avoid. It's a good list of things to look for and engendered quite a discussion in our internal Musketeers IRC.

An honest write up with first hand details of the shortcomings of couchdb in production. There's a reason to stick with proven technologies and not simply chasing the latest shiny. Not saying sauce labs did that, just sayin'.

Carl Erickson observes that a small, boutique team of developers can be massively more productive than a larger team.

Matthew at DogStar describes his PM toolbox today, The Project Management Tool Box | Opensource, Nonprofits, and Web 2.0.  It's a detailed and well organized list, and I think reflects a very practical approach. The first thing that strikes me, is the overwhelming amount of tools available to the would-be PM.  Certainly, there is no lack of tools out there.

Seems to be the next big thing in software processes land. So, hire competent peeople and try to get out of the way.

These things are all the basics you pick up by reading Learn How Not to be a Complete Failure at Software Development in 24 Hours. None of it will make your developers any less prone to do stupid shit, and none of it will prevent your systems administrators from roadblocking developers just for funsies.

Devops Is a Poorly Executed Scam

Clone ... What could possibly go wrong?

If you're a coder, you've already heard about distributed version control systems (DVCS) and git in particular. I was content, almost complacent, in my usage of subversion to manage my source code, both for personal projects and at work.

Jow Maller outlines a straightforward system for using git to manage code from development copies and branches through production. The fact that deployment to live is automated, but I'd be worried about broken or unreviewed code getting deployed unintentionally. I think the best way to prevent that is to have live be its own branch, and then pushing changes to the live branch once they've been reviewed, tested, and blessed.

Iisolani provides a thorough dissectin of how these new-fangled #! urls you are seeing all over the newest sites on the web are prone to breaking both the web experience and a site itself.  I think I see a hint of "we-know-better" from the developers rushing out these new sites and re-designs. HT: Jason Lefkowitz

Lessons: Use Cases matter, and programmers (the users in this case) will choose tools that are both simple, in that they are not complicated/over-engineered, and easy to use, requiring little setup and code to accomplish a task.  For parsing data with PHP, constrast using something like SimpleXML or DOMDocument (which is light-years better than where we were in parsing XML just 5 years ago), to just doing json_encode() or json_decode().