Agile: the new "Share Options"?

I'm currently working on my own project, and honing some new skills, but keeping an eye on the jobs market, just incase anything stunning pops up, or I just plain run out of money, and I'm spotting a rather strange trend.

The job advert goes something like this:

"Come work for us, we do Agile!"

followed by:

"We love TDD, BDD, Pairing, Continuous Integration, blah blah blah, agile, Agile, AGILE!"

And very little about the thing you'll actually be doing, team size, the company, compensation etc.

This reminded me of something.

Back in the day (as we .com bubble veterans like to call it), the lure companies were selling was something called "Share Options". Basically it went like this:

"Come work for us, you get Share Options!"

"Dynamic, fast growing, .com, blah blah blah, Share Options!"

And this is when came to be known as (at least to me)  the .con.

Essentially, it meant that you would work in a dirty, crowded, hyper-competitive, testosterone-filled office, for 10 hours a day, for peanuts and the occasional bottle of free beer, and if you managed to survive for a couple of years, you'd get "Share Options", which you could then sell, at some vague point in the future, and thus retire to that playboy lifestyle you'd always dreamed of... That is, if the management hadn't bankrupted the company by then, the economy hadn't collapsed, the company was actually worth anything and had been successfully floated, or been bought-out by Google...

Of course, in most cases, the company went bust way before anyone got to sell their shares, either through stupid growth models, running out of funding, the economy going bang, someone doing something better/sooner, or very occasionally, actually working out how to make money out of it.

So, why was I reminded of this?

In a company that values the holy dogma of 'Agile' above anything else, you will work harder, have less time for original creative thought, be less independent and more micromanaged, learn less, have little personal sense of achievement, and end up a burnt-out shell with little love of coding. In short, you'll only be of any more use to the world as an iteration manager.

On the other hand, in a company that values its skilled staff, gives them space to develop, and loves its product above anything else, and is willing to try a few agile techniques and technologies that seem to work for it, and throw away the ones that don't, you may actually have fun, and achieve great things you are proud of.

I've met people who are really (really) keen on 'Agile', they just love it! They like to tell you how great it would be if everyone paired (it's not), and how brilliant doing TDD 'the right way' is at preventing defects (it isn't), but then refuse to pair with anyone, and you look at their code and there are very few worth-while tests, or even none at all! Then they get the hump and move on, apparently because 'nobody here does Agile properly'. Yeah, that's because it's an illusion! There is no 'Agile', just a bunch of fairly common-sense stuff such as writing tests for tricky code you might get wrong, and asking people for help when you need it.

I will never, ever, write a test for a flaming data bean, even if it reduces your code test coverage. I will, however be delighted to write a really good bunch of tests for something that actually has some complexity, so the next guy who picks it up without making any real effort to understand how it works, might not break it, and you know what, I might even write some of the test before I've written much code!

I'm also quite happy to pair, if it means work gets done faster, or I'm helping to break in a new member of the team, or leaning something new myself, but pairing every day, often on something ludicrously simple, just because 'we pair' makes no sense: no-one ends up owning the code, nobody takes responsibility for it, and no one really knows anything about it. I'm very happy to explain it all later, and answer questions too. Yes, I'd like to talk to you! And if I'm not there today, or indeed, anymore, you know what? You could even sit down and read the code! Amazingly, the code shows, in detail,  exactly what will happen when you run it! I'll even leave 'clues' in there in the guise of readable class and method names, clear 'intent' and, gasp, helpful comments for any tricky bits ('Noooo!' scream the 'Agile' worshippers).

Anyway.

I don't think I'll be taking any of those jobs.