Today is software process day. When I got to work, someone had forwarded the following article around: Lean Programming and Part 2. Some of my favorites:

[W. Edwards] Deming maintained that poor quality was engendered by systems that thwarted the workers' desire to do good work.

Sakichi Toyoda had invented an automatic shut-off mechanism that stopped a weaving machine the minute it detected a flaw (such as a broken thread). [Taiichi] Ohno expanded this concept into car manufacturing, insisting that each automobile part be examined as soon as it was processed, stopping the line immediately when a defect was found.

(sounds like continuous integration, no?)

We did have some quality problems, and it took a month to fill most orders. Special orders were another matter, however: The division vice president would often call to expedite them for important customers.

Sounds like some projects I've been on. Nothing gets done until it gets escalated to the CIO.

we used to think that it would be ideal if our marketing department could forecast exact market requirements

I'm fighting that battle right now.

Often when software development environments under-perform, the instinctive reaction is to impose more rigid processes, specifying in greater detail how people should do their jobs

Or hiring pointy haired bosses :-)

We must improve future project performance by learning from existing ones.

So the question remains: will it work for me? Are we going down the same road? Maybe it works for an assembly line, but I don't know if I want to work on an assembly line, or pick cotton for that matter. I'll see if I can figure out where this is leading me.

Five Worlds:

Last week Kent Beck made a claim that you don't really need bug tracking databases when you're doing Extreme Programming, because the combination of pair programming (with persistent code review) and test driven development (guaranteeing 100% code coverage of the automated tests) means you hardly ever have bugs.

[Joel on Software]

We've been kicking aroud XP at work for the last couple days and one thing that came up was whether pair programming really acts as a code review and whether you can get true test coverage from unit tests.  Joel says maybe, if you're doing a project that lends itself to that.  XP came out of a development effort for internal corporate software, and shows those scars.  RUP has its roots in the defense industry and is definitely designed to meet CMM level 3 requirements and a GSA audit.  MSF came out of Microsoft, so it reflects that world.  Joel may make fun of big CRM systems, but he's never had to build a system to maintain payroll for 100,000 employees.  It sounds like shameless hedging when someone tells you that the answer to your question is "it depends", but it is the honest answer.  So if it's true that Qwest is switching to XP company-wide, maybe that will work for them because they're probably mostly developing internal apps for customer service agents and repair technicians, but it might not work for us because we have a different target market.