A Tale of Two Recruiters

It was the best of recruiters, it was the worst of recruiters ...

TheHackerCIO was recently impressed by a recruiter. That's rare. Really rare. But he always gives credit where it is due, and in this case, justice demands praise. And the reasons can be seen by contrast with another recruiter. Comparison and contrast always highlights important points. 

Unfortunately this pair -- both hero and villain -- have to be anonymized: to protect both from embarrassment, but embodied in very different forms. Those rightly abashed at their conduct have a very different emotion from those uncomfortable with public praise. 

The only justification for putting forth this contrast is the principle it underscores. And principles have to be embodied in the tersest wording possible, so they can be used. This one is newly articulated by me, so here goes an attempt to formulate it; after that we'll examine the illustrative examples.

The principle is: Seek those who also seek work-arounds to procedures. In other words, when bureaucracy impedes, those who evade it are the ones you want to work with. 

Let's see the villain first. Enormous Behemoth Recruiter contacts TheHackerCIO with a tempting position. I've taken the liberty of excerpting all the temptations and buzzwords, claiming:

• very beginning stages
• learning new things everyday
• vision of changing
• brand new approach
• building great software
• energetic trailblazers
• creative mindset
• rapidly deploying
• competing with ... Google
• competing with ... Apple
• competing with ... Amazon
• Technology is the ‘product’
• innovation through technology products
• quality
• innovation
• transformation
• innovation
• quality
• speed
• smaller product teams
• quality 
• speed
• effectiveness 
• A/B testing
• frequent releases
• adoption of “agile”
• very large transformation

The catch was that you had to enter your whole resume into their on-line system. You couldn't simply email them a resume. And, supposedly, their automated system would pull this information from LinkedIn. But it didn't work on mine. I suggested an alternative to the recruiter, who claimed to have direct contact with the CIO:

=====================================================================================

I'd be happy to have you present me to the CIO. Can you use my LinkedIn 
profile? LinkedIn seems to have been failing to import as it is supposed to. 

=====================================================================================

But the reply came, SOP, SOP. 

======================================================================================

Hi James, 

Thanks for the reply. I can’t present anyone unless they formally apply to 
the position. Standard protocol at <NameDeleted>. Once you apply I can 
certainly present your information to the management team. Below is the 
link to apply to the position. Please let me know when you have completed 
your application so I can submit everything as soon as possible.

<snip>

======================================================================================

Notice, by the way, how the reply suddenly backtracked away from direct presentation to the CIO. But I ignored this bad sign, and wasted quite a bit more time attempting to use the broken, but mandatory system. Finally, TheHackerCIO came to his senses. I realized how I had been deluded by the Silicon Valley location and various claims and buzzwords and wrote the following: 

======================================================================================

Hi <Name-Deleted>: 

Just to let you know, I've wasted too much time messing with this. You site will not load my information from LinkedIn. I've tried it from a mac with Safari, Chrome & Firefox and with a Windows 7 box running Chrome, and Firefox. I suppose I could enter my details manually, but the experience reminds me that I don't want to work in a place with a firmly bureaucratic "process" that can't be gotten around. 

I've worked for clients larger than <NameDeleted>, and universally I've been stymied from their programs of alleged "change," by the bureaucracy. So, I'll take this as an indicator that I should focus on smaller clients where these kinds of impediments are either not present or can be worked around. 

This is just by way of explanation -- thanks for your interest. 

Regards, 

James 
======================================================================================

Now we turn our attention to the contrasting example.

This recruiter, (we'll call him Ted, to ensure anonymity) when I responded that I had to update my resume, and could he use my LinkedIn profile and/or blog in lieu of it, responded "yes." He would see if there was interest using those materials, and wait for me to get an updated resume to him.

He copied me on the correspondence, where he presented my LinkedIn profile & the URL of my blog, and asked the client to see if there was any interest, at which point something could be entered into the applicant system.

Now that is an example of putting the substance ahead of the form. It's an example of working around the bureaucracy and procedures, which, after all, were designed to get good candidates, not make the whole experience hellish.

This is what good software developers and technologists of every stripe have to do everyday. When something doesn't work, you have to generate work-around ideas and try them, until you find something that works. Why should technology recruitment be any different? Is the goal to place the right person in the right position, thus benefiting everyone? Or is the goal to adhere to the sclerotic bureaucratic process? Unfortunately, far too many believe that process automates success.

But Process Never Automates Success. (the Rothering Principle)

And, TheHackerCIO works with those who work-around obstacles.

I Remain,

TheHackerCIO

Software Architecture

Today, even the notion that there should be software architecture is up for debate! Regardless of what verdict one arrives at,  it is a good thing to examine whether something should exist prior to investing time studying it.

[editorial note: this post commences an occasional series on Software and Enterprise Architecture, in which I hope to collect all the principles into one convenient place. We begin at the beginning: should there even BE a discipline of software architecture? ]

There are a number of "nay-sayers." But I think they can all be classified as variants on the notion of "evolutionary design," which contrasts strongly with the notion of engineering, design, and deliberative architecture. The idea is that design is an emergent property that will manifest itself as the work unfolds. The Wikipeida article puts it this way:

Emergent design in agile software development[edit]

Emergent design is a consistent topic in agile software development, as a result of the methodology's focus on delivering small pieces of working code with business value. With emergent design, a development organization starts delivering functionality and lets the design emerge. Development will take a piece of functionality A and implement it using best practices and proper test coverage and then move on to delivering functionality B. Once B is built, or while it is being built, the organization will look at what A and B have in common and refactor out the commonality, allowing the design to emerge. This process continues as the organization continually delivers functionality. At the end of an agile release cycle, development is left with the smallest set of the design needed, as opposed to the design that could have been anticipated in advance. The end result is a smaller code base, which naturally has less room for defects and a lower cost of maintenance.^[1]

As emergent design is heavily dependent upon refactoring, practicing emergent design without a comfortable set of unit tests is considered an irresponsible practice.^{[citation needed]}

I have to laugh at the last line: "practicing emergent design without .. .[snip] ... is considered an irresponsible practice." It reminds me of the Moliere comedy, Le Bougeoise Gentilhomme, where the man finds he has been speaking prose all his life and didn't even know it. Likewise, many a team has been practicing "emergent design" for decades and thought they just hadn't used an architect.

There are a lot of parallels here with methodology pathology. Just adopting an agile or iterative methodology is not a silver bullet.  Process does not automate success! [The Rothering Principle] TheHackerCIO has seen plenty of projects with churning iterations that never seem to get anywhere; just as he has seen Waterfall projects that can't get out of one phase and into another, or that allow phase leakage. Process alone cannot ensure the absence of pathology. The Capability Maturity Model of Carnegie-Mellon seemed like a good thing, and I was a proponent of it, until I worked with outsourcing companies in a particular subcontinent (which will remain unnamed), all of whom were CMM level-5 certified, and none of whom could deliver one useable module of code to our project. I'd love to have seen a post-mortem analysis of how their coding failures made it back into the "feedback-loop" of their CMM program!

One manifestation of this attack is the TDD methodology. Taken rigorously, it directly assails the need for architecture: you are to take your assigned User Story from your Product Backlog, and after coding your first test case -- mind you, not one line of actual code has yet been written!!! -- after coding that test case, you now enter the "red" state, and are to determine ... what?

• The best way to structure your code to allow for future eventualities? No! 
• The best approach to code this method, so that you can reuse existing code? No!
• The most elegant set of methods that will allow for maximal flexibility? No! 
• A higher degree of generality to accommodate use cases that are going to come? No!

The principle adhered to here is YAGNI!

In contrast to attempting to architect, engineer, or design, one is supposed to take the directest, clearest, fastest path to implement the user story, at least a portion of the user story, and nothing but the user story. You are to "just do it," as the Nike slogan goes, and when your test-case passes, you enter the "green" state. At this point, you are to consider refactoring the code you just wrote, to achieve whatever an Architect or designer might have attempted upfront.

This is a direct assault on the notion of architecture, or on the need for it.  There are others.

Next up: Patterns and Pattern Languages

I Remain,

TheHackerCIO