Would you Employ only a Certified Software Engineer?

I posted the following in a group on LinkedIn after a question in the group asking what the focus of the BCS should be in 2010:

Would you employ an amateur, DIY bricklayer to build your wall?
Would you employ someone who's read a couple of accountancy books to be your accountant?

Chances are you answer is "no".

Would you employ an amateur hobbyist coder?

Chances are, the answer is "yes".

Would you build a brick wall for yourself, or would you help do the books for your club?

Chances are, the answer is "yes"

Computer programming (and that's my background) is an area where everybody feels that they can do a bit of DIY bricklaying - especially with some scripts and a spreadsheet which then becomes a business-critical application.

Professional accreditation is all well and good, but there is no difference (from employers' perspectives) between a hobbyist coder and a CITP-holder.

Other professions (law, accountancy, medicine) require their professionals to have some professional training as well as their basic qualifications. It's also difficult to be an un-registered lawyer, accountant, doctor, etc. So there is a consequence for not being professionally recognised.

Maybe we need a new CSE for the 21st century, a Certified Software Engineer. The holder of such a certification would have to demonstrate good software engineering skills: requirements elicitation, requirements modelling, solution design, coding standards, testing, source control, documentation, maintenance, etc.

Experience Counts for Less?

The Wall Street Journal article "Dangers of Clinging to Solutions of the Past" illustrates the value of challenging assumptions and the inspect-and-adapt cycle. Whilst the article boldly asserts that increased experience leads to increased project failures, this is attributed to an increased confidence on behalf of the project managers concerned.

I would like to add that it is of little use to know that a practice worked previously without knowing why it actually worked, and conversely one should also know why something did not work in a particular situation. By knowing the "why" one is able to apply the experience to the appropriate situation.

We can only discover the reasons by taking the time to ask ourselves what those reasons are. Scrum's retrospective meeting (a post-iteration review) generally poses 3 questions:

• What went well?
• What went wrong?
• What to do better, and how?

I would now say that the 3 questions should be posed as:

• What went well, and why?
• What went wrong, and why?
• What to do better, and how?

Peopleware: you must read this book!

Many people have heard the quote that the best software developers are 10 times more productive than the worst. Whilst I was reading the course material for my course in project management I came across the source for this statistic:

"Peopleware: Productive Projects and Teams" by Tom DeMarco and Timothy Lister, 2nd edition, Dorset House, 1999

Reading this book you get to see the rest of the results:

• the best developers are 2.5 times more productive than the average - so there are a lot of very unproductive developers out there
• the best developers are in development teams that are 10 times more productive than the worst teams - it's not just about individuals, but who they work with, who they work for and in what kind of environment they work
• people are more productive when they have fewer distractions - obvious, but lost on many managers
• Parkinson's Law was a joke about a bureaucracy, not a general observation
• higher pressure does not improve productivity and/or quality

After just reading a couple of pages I came to the conclusion that this book should be made a mandatory read before anyone takes on a new position as a manager - including, or especially, several of my previous managers!

I've only read a few chapters, but my enthusiam shows no bounds.

Nam et ipsa scientia potestas est

At a reception for us fresh-faced (well, maybe more like spotty-faced) computer science freshers in 1987 I was asked by a fellow student what I thought the best computer was. My answer was, "Orac from Blake's 7"

Thinking back it may not have been such a facetious answer.

Orac was powerful because it networked with other computers, not just sitting there on its own like the traditional super-computer of science fiction (and super-computers 30 years ago). Orac had the ability to communicate with all other computers that carry tarriel cells - the basic component of all computer systems in the Blake's 7 future, designed by Ensor (Orac's creator) at a young age.

Able to mine any data on any computer system it had a vast wealth of raw data at its disposal that it could process into useful information. Thirty years on from the creation of Blake's 7 we are beginning to see the wealth of information that can be provided by the Internet and the beginnings of practical distributed computing in the form of cloud computing.

As Sun Microsystems says: the network is the computer