Q are wonderful sponsors of my Technology Radar Group, so I don't mind plugging them. If I call them Headhunters, I'll get a nasty-gram, so I won't do that. :-) But they do recruit people. In the technology space. And I haven't seen any irritating spam from them. They sponsor a whole lot of technology Meetups, and for that I'm deeply grateful.
So I didn't mind giving them some advice on how Technical Fitness is at least as important, if not more so, than Physical Fitness. Although, naturally, both should be attended to. Mens sana in corpore sano. But we hear so much more about physical than technology fitness!
Great attendance & surprises indeed last night at the GeekBookClub, more properly called the LAJUG Study Group.
We began the new book: The Cucumber Book, seen above.
It's a bit Ruby-esque, but applicable to Java via the download of cucumber-jvm, which I'll need to investigate.
So, I got my MacBookProRetina loaded up with Ruby as a prerequisite for the Cucumber install, and followed the appendix without serious issue to get a working cucumber installation up to try things out. And I entered the first bits of chapter two's "First Taste," and got the same results.
Apparently, the whole Cucumber/BDD -- or Behavior Driven Development -- is based around attempting to provide a communication tool that can involve business people as well as developers in producing executable specifications.
To begin with Cucumber is a command line tool.
That's cool, to the inner Hacker that constitutes TheHackerCIO, because GUIs are for those who can't Hack. Your mileage may vary.
A feature is a flat file that contains plain-text, ordinary language descriptions of one or more scenarios.
A scenario is a list of steps for Cucumber to work through. These scenarios must follow a particular syntax so that Cucumber can work through them.
Gherkin is the name for the syntactical rules required of the scenarios. Gherkin uses keywords such as Feature, Scenario, Given, When, and Then to provide the needed structure to the DSL.
The steps, or step-definitions are where Ruby programs actually get bound to the specification, thus making them executable.
The essential point of all this is to make it possible for business -- that it, non-technical -- people to get involved in writing acceptance tests. That seems like a good thing.
The big surprise in last nights discussion was in one new, first-time attendee. Newcomers are freely and warmly welcomed at our book club; at whatever level and from whatever technology background. And this newcomer was already very familiar with both Ruby and Cucumber!
So, instead of a discussion among people all eager to learn a new technology, we had an interaction with someone who already new and HATED the technology! That was a twist! This person was coming to try to see whether she could be convinced of the value of Cucumber from the Pragmatic Programmer book!
We spent quite a bit of time trying to understand what her issue was with the tool, and we all quite happily viewed a demo of how Cucumber works, which she whipped up for us on her Macbook and ran.
Seeing a live demo on the spot certainly made it a lot easier to grasp the whole essence of Cucumber. It's amazing how much superior a tutorial is to reading, no matter how much I like reading.
Valuing and dis-valuing are two sides of the same coin! To love spicy-hot foods means, inversely, that you don't care that much for bland fare. And so, the passionate values of TheHackerCIO lead quite naturally to an equally strong distaste for some things in the technology world.
Deliverables that were technically in order, but didn't provide the needed functionality.
Dispute with the client about the contract.
I'm not sure if it is technically true, but rumor held that this particular consulting group used their Legal Department as a profit center. And such appeared to be the case, at least on this occasion.
Why anyone would hire an accountant when they need a programmer is beyond me. Can you imagine a startup doing that? "Yes, Bill, I know you asked for 3 Ruby programmers, but I found these excellent recent graduates of a major, prestigious university who know all about Anthropology, Sociology, and Psychology, and are backed up by an organizational expertise in accounts-payable, accounts-receivable, and inventory-control. Plus, they've all been through a 10 week "boot camp" on how to manage your projects." Yeah, that would fly.
One of their characteristic gambits is the initial use of top-level experts who really know their stuff. But these quickly dissolve into the woodwork and are replaced by ambitious 21-year-olds whose knowledge of technology is about as deep as a kiddie scripter, but who has been trained in a boot camp that methodology can replace expertise in producing results.
The combination of youth and arrogance is typical and particularly ugly. And so, that's why I call this particular phenomenon: The MBAhole.
TheHackerCIO no longer works on projects with MBAhole defined management.
But he will offer free advice to those who chose to do so.
Instead of putting accountants in charge of your technology project management, put your legal department in charge of it. That way, they'll be ready when the project gets closed down.