Asymmetric Lock-in

That's what I call a policy of certain agencies or individual recruiters whereby candidates are told that if they are sent on an interview they must commit up front to accepting an offer in case one is made.

An example of asymmetric lock-in (first item)

What makes this lock-in asymmetric is that the client company is never committed to making an offer in the interview.

This is problematic because one of the fundamental tenets of "free enterprise", as we are all taught from birth, is that the relation between an employer and a human resource (formerly a "person") is one of full equality and symmetry.  This is why unions are unnecessary, as we are constantly being told these days.

I can understand if recruiters are chasing commissions or points or whatever that they want some guarantees when they spend time on something.  I'm sorry, but there are no guarantees in this business:  free enterprise is about risk.  But I will guarantee that if I find out there's a policy of Asymmetric Lock-in,  I'm not playing.

Achtung!

Michael Feathers has an excellent post on a hitherto unremarked value of builds, including this line:

Development is an attention-focused activity, and for me at least, a sense of closure is important for that focus and important for morale. 

And for me, this is yet another example of the critical importance of rhythm in the development process. XP is a hierarchy of rhythms,  from regular releases through iterations and daily standups down to the Red-Green-Refactor cycle.

But it's not just XP:  every developer who hasn't burnt out develops some kind of rhythm. In an environment based on an ideology like Waterfall that's seriously disconnected from reality, corruption is inevitable, and the developer's personal rhythm is not going to be good for the project.  I've run into this on my current project, which is "corporate Agile" - i.e., largely about daily standups. I've tried to convince team members with no real Agile experience that TDD is personally satisfying. Many of them don't buy it, not for intellectual reasons, but because it's completely contrary to their own rhythms, which involve writing a lot of code, building up the tension, and then manually testing it, which provides the release.  It leads to complex and overengineered code that's nearly impossible to create automated tests for.

I think Kent Beck's most original insight about development was that it's done by humans, not machines. (Okay, so it wasn't that dramatically new - Weinberg brought psychology into the methodology conversation, even if it was based more on an abstract ideal than a felt reality.)