Andy's Mind

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

Simple is beautiful. But simple is also right. Ideas and thoughts worth anything can be expressed clearly and briefly. Complex systems that work are build from simple components according to simple ideas.

Take Internet for example – most of the protocols that make it what it is are beautifully simple, concentrated on their purpose, describable in a new sentences. In fact, it takes no more than 20 minutes to explain to any computer-literatre lay-user all they need to know to understand why the Net works.

Opposite is also true. Complex visions, ideas requiring lengthy, vague explanations are crap more frequently than not.

It also applies to business. Success comes to those focused on a simple goal, not to those who want to catch all the birds at the same time and completely change the face of the planet. Simple ideas, ambitious goals and hard work are the step stones on the path to achievement.

I thank my father for teaching me to be always suspicious of ideas that can’t be told in a few words, brief and simple.

I’ve been into web applications for some time now. First I used them, then I proposed them as solutions in some consulting projects then I got involved as development team manager in creating one (a billing/CRM system). But only now it occurred to me that ubiquitous Internet access and popularity of web applications are interlocked in a self-powering cycle.

As Internet access is more and more popular people start to use web applications more. As they use them they are more dependent on Internet access and thus demand it everywhere. One could extrapolate that once Internet access is available always and everywhere web applications will also dominate. And, conversely, if people indeed use web apps more they would need Internet access always and everywhere to keep using them.

It is interesting to see how the idea of Internet expressed in its name – the net to connect all nets – persists despite some trying to change it. This has profound implications for businesses trying to operate in this virtual world. Two clean and clear strategies can be seen – one is of an access provider and the other is one of an application/content provider. Those two species in the Internet ecosystem are dependent on each other, but they are distinctly different.

For an application/content provider the best idea is to reach as wide an audience as possible – potentially all Internet users (limited only by the languages they use) – with a clearly defined, appealing application set or content offering. Traffic means all to such businesses – no matter if they live off advertising or paid subscription. The more eyeballs you get to your web page the more money you make, period. Hence, limiting access or availability to a particular ISP or network is a bad idea, because no operator can match the number of potential users the Internet gives.

Conversely, for an ISP an opposite strategy is better. Such a business should focus on destination agnostic access. ISPs sell an easily-comparable commodity of access to all the Internet has to offer with only three simple dimensions of quality: price, reliability and speed. For them keeping a customer as long as possible and getting as many of them as possible per real meagbit of bandwidth is crucial. And to do that one has to stick to the basics – no amount of gimmicks, applications or exclusive content will ever help if the access is slow, pricey and breaks up all the time. It is so because no operator can match the amount and quality of applications and content available on the wide open Internet.

That’s why it is so rare these days to see people using e-mail addresses provided by their broadband operators. And why almost everyone uses some kind of webmail.