The Incident of the Fumbled Phone Screen

It was a technical screen led by an architect at a company that billed itself as Agile.  We started out with a general conversation about good OO practice and Agile development.

Then he asked me about HttpRequest.  I described its general behavior, but I had the feeling I wasn't satisfying him.  It had been close to two years since I worked with a Java app that used HttpRequest.

Later the recruiter who had set up the screen called to say the interviewer loved what I had to say about OO and Agile and admired my passion, but felt I didn't give enough detail on HttpRequest, so they were taking a pass.

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.

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.)

What am I looking for?

I'm editing this post over time - it's in chronological order - latest last.

20110921:   I'm looking for work.  Here's what I'm thinking would be ideal (this changes because I learn something new on every project - I'll keep this post up to date):

A long term (contract or perm) engagement with a team working on legacy apps.  That's where the real challenge is - greenfield is easy.  I'm dead serious about this.  I know: every developer wants to get in on the ground floor of the next big cloud/social/multiplatform/HTML5/your-hot-language-here killer app.  Not me.  I do that at home.  At work I want a challenge of a particular type: the combination of technology and social interaction that is Agile and the jungle of legacy code.

Notice I say "team".  Ideally this would be a functioning XP team (if you think I'm talking about an old but still kicking OS, our relationship is already in trouble).  Or - better: a newly formed team in an organization that sincerely wants to go Agile and understands that Scrum is about management, not development:  XP is a Agile methodology for developers.

I recently had a disastrous stint with a company that did not understand Agile.  I was actually told not to talk to other developers about what I was working on, because they were "busy".  Right.  These folks misrepresented themselves as open to Agile.  They weren't - or more charitably, maybe they just didn't know. Oh sure, they had daily standups.  But in terms of development process they were mostly in the Cowboy/Hero mode.

As a matter of fact, I'm a terrific team member and mentor.  I always work Test-Driven (TDD and BDD) even if nobody else is, but I'm glad to show teammates how productive it can be - I gained some converts on the project I'm now rolling off.  (If you have a problem with TDD/BDD - again, our relationship is already in trouble.)

I am absolutely not interested in being an architect, QA tester, business analyst, DBA, Websphere administrator, etc., etc.  I'm a software developer:  J2EE, DotNET or Rails, frontend, middle or backend - ready willing to learn new OO or functional languages and frameworks and work in new domains.  (Of course, as an XP developer I have done all of the jobs above - as part of my normal development duties.)

Yes - I need to put food on the table and in bad times I take bad jobs.  Fortunately this is not a bad time.  But you'll have to be honest with me:  if you think Agile - XP in particular - is a bad idea, or it's being forced down your throat by Corporate and you'll show them!, better you don't even phonescreen me.

20110922:  Did I mention that I live and work in Chicago and will not travel or relocate?

20111011:  Kent Beck recently said a lot of what I'm thinking  in My Ideal Job Description.

20120609:  After a year as the primary developer on Northern Trust's highest profile application (Goals Driven Investing),  I've learned a lot about teams, code quality, process, etc. in a corporate environment struggling to become Agile.  One lesson: how quickly a greenfield app becomes a legacy app when ACPs (Alien Cowboy Programmers) are involved. Will be posting more on this soon.

20121201: Not much to add except:  TDD is non-negotiable.  I will not work in an environment that does not allow developers to work this way.  It's a matter of safety, both for the software and its developers.

Testing and Design

Just watched a great video - The Deep Synergy Between Testability and Good Design, by Michael Feathers.  Combining this with JBrains' blog post How test-driven development works (and more) and his video Integration Tests are a Scam would make an excellent intro to TDD, and maybe I'll get a chance to use it soon.

Not so fast, Otaku

That last post was a little over the top, particularly the part about "good, true and beautiful".

Strike "good".

Although XP does have an ethical component in terms of how team members should relate to each other (and, to some extent, to the customer),  it doesn't deal with some wider issues.

You might never do a website for Kim Jong Il or Osama bin Laden.  That's an easy call.

What about Goldman Sachs or BP?

That's me at the pairing station, practicing my religion

The metaphor of programmer-as-craftsman and the concept of apprenticeship are great up to a point ... and that point is where it gets medieval.

I don't think software development is a craft - I think it can and should be (and - in XP teams - is) an alloy of art, science and religion.

For models, I look first to the Renaissance, to people like Michelangelo, who studied anatomy as seriously as any practitioners of "scientific medicine" of the time,  and to DaVinci, who studied physics equally seriously.  They were both also brilliant artists.

The medieval role that comes closest to a model for me is not the craftsman but the monk  - particularly the scribe whose faith in a divine perfection drives the work.

But the scribe is a soloist.  And so were Michelangelo and DaVinci.

Renaissance artists who weren't simply soloists were businessmen.  The master/journeyman/apprentice hierarchy in the art biz survives even now - e.g., Andy Warhol and his "factory".

What happens when software development organizations use the guild as a model?  In two big "Agile" consultancies I know of and will not name here, the result is ... architects.  Oh yes, they code.  But they also do BDUF.  And they radiate "authority".  This doesn't meet my understanding of Agile.

XP is not a solo activity but a communal religious action with a particularly clear vision of the sacred.  In OO we have an esthetically and logically balanced basis for design, still evolving.  In XP, we have a concept of perfection - the sacred - that is dynamic and minimalist:  the simplest system that does exactly what the customer wants, no more no less.   (I'm using the term "sacred" here the way social anthropologists since Durkheim have used it - there's nothing intrinsically supernatural about it,  except to the extent that symbols themselves are supernatural [for which I will make a case elsewhere].)

The closest modern analogy might be a Charismatic congregation (Catholic, Protestant or ...?)  with a lay leader who is not a priest (architect), who has no special connection to the sacred.  These groups are radically democratic.

What makes XP more than any of these models is the unification of art, religion, science and commerce.

It's the wisdom of a small crowd focused on the good, the true and the beautiful.