When things go wrong...

Mon, 06 Aug 2007 10:35:58 GMT

When incidents arise I feel the role of the architect is to mediate: to get the information needed to steer the technical team, to help identify the problem and to ensure that the solution may be deployed without making things worse.

Recently I've been involved in several incidents where concurrency issues, session hijacking, sequence number conflicts, etc. were floated as possible causes for complaints that were being raised on a website.

While all of these might be possible causes for the symptoms, they're not particularly plausible. It reminds me of a tale of a man who drops his keys on a dark street. He keeps walking until he finds a street light and starts looking for his keys there. While they're not likely to be there, he'd be more likely to find them if they were. I've seen people looking for explanations to production issues in outlying places first before trying to shed some light on the problem. I've certainly done the same when the adrenaline's pumping.

In the case of my recent production incidents, a look at the data showed that the most likely explanations were human error and an ISP recycling a user's email address.

Don't forget the people

Mon, 27 Feb 2006 22:26:29 GMT

Human behaviour in IT has been sitting in my newsreader for a while now and I've been meaning to post a link to it. Very rarely do people in IT write about the softer side of the job and it's always interesting when they do.

Being someone in a senior position not only are required to have an in depth understanding of technical details, but you are demanded to understand your peers and your client better. This is something very difficult to do because it's not something that you can read from textbooks or from any kind of book. As a senior person are in a position where we need to gain respect from our peers, and the respect that we need to get are not based on our technical capability but from our "soft skills" capability.

...

Humans are more complex than the most complex algorithms there is in this world, and that's the challenging part. By understanding and able to work with humans we will be able to make the people around us happy and this in turn will make the project more successfull. It's understandable that it's not possible to please everybody but the more we try to do it the more people will appreciate it and the more positive things will come out of it.

When I've delivered architect training/mentoring, I've always said the role was about balancing the functional and non-functional requirements through architecture/design, development, mentoring and quality assurance. I'll be modifying this in the future to include people.

Coding the Architecture - humanbehaviour tag

When things go wrong...

Don't forget the people