July 2007


Adam showed me this web site the other day where they protest the idea of certifying agile software specialists. He agrees with the points made there – and I do too. We just don’t agree on the conclusion.

I don’t think certificates are all that bad because I do accept the imperfect reality we live in. And that reality is that a) there are (quite many) people who believe some kind of paper with a stamp on it (like a university degree for example) defines what someone is capable of and b) because of the pace the world moves at almost no one has time to properly evaluate candidates for a job as complete human beings (hence what I call “database hiring“).

Because of that it is a fact, though sad, that the more certificates and abbreviations around your name you have the more you are likely to get hired. That’s why people do invest in getting degrees and other certificates and it is a sensible, rational investment in their careers. It won’t replace real knowledge and experience, but it so much easier to get past the door and show them if you have some paperwork.

But from the employer’s point of view certificates have some positive aspects too. Some of them are hard to get and require some real effort (like some university degrees or things like PMP). While that doesn’t automatically guarantee a potential employee will indeed perform in the real world it makes it more likely – and that counts. It also shows some dedication to the chosen profession or specialty and willingness to spend time, work and – yes – money to better oneself, get new knowledge etc.

Last but not least – not all trainings are bad. But getting your employer to pay for your course might be easier if besides something as intangible as knowledge you bring back something to adorn the office wall – like a certificate. I know no one will admit that – but isn’t it so? Again it seems those indeed stupid pieces of paper have a use.

I’ve just read yet again on some blog someone complaining that agile teams don’t document what they do, producing unmanageable, messy code. Not true, agile developers do create documentation. The difference is that they don’t fetishize it. By that I mean that documentation (models, descriptions, etc.) are seen for what they really are – mere tools, a scaffolding for the real product which is the working code. It’s same about other things – like modeling, analysis, design, testing etc. – all that is by no means cast aside by agile practices. It is just applied differently (for example testing not of the whole product in the end, but at every step) and never mistook for the real deliverable.

I suspect this superstition that “agile don’t document” persists because of some teams that think “agile” means return to “good old days” of cheerful coding without designing testing etc. This is just poor engineering, not “agile”.