Parsi Lamb

this is a fantastic curry and really easy to make. It looks surprisingly ordinary - but the results are fantastic. I've presented the recipe in a way which is designed for the cook - dividing the recipe into lots in sequence. I find this easier than rereading the list of ingredients and the recipe to find out what goes where.

Lot 1

4 Large Onions sliced
4 Green Cardoman pods
3 cloves
4 cm cinnamon stick

Lot 2

50ml of water
2 garlic cloves
thumb sized piece of ginger
(or two tablespoons of ginger and garlic paste)
1.5 tsp of chilli powder
1 tbsp ground cumin (I freshly grind mine)
1.5 tsp of turmeric
1.5 tsp salt

Lot 3

3 tomatoes chopped
750g of cubed leg of lamb
1 dried red chilli
4 green chillies sliced lengthways
200ml water

Lot 4

3 tbsp chopped fresh coriander

Method

1. Heat 6 tbsps of Vegetable oil over a medium heat then add Lot 1, stirring occasionally for 20-25 minutes until the onions are golden.

2. Add the water from Lot 2 which drops the temperature then add Lot 2 and cook for 1 minute

3. Add Lot 3 then simmer for 40 minutes - or until he lamb is tender

4. Add Lot 4 and serve or you can freeze for up to 6 weeks

Serve with boiled basmati rice.

Time for some Knowledge - The Enhyper Library

http://enhyper.com/lib

Way back in 1998 I had a job looking after the development environment for a tier 1 while back. One of the things I did which proved useful was put together a library of links using software from Gossamer Threads. as a first pass at Knowledge Management.

This was a pre-wiki tool which allowed you to arrange a series of links hierarchically and let users rate them. It also had a newsletter feature which I used to run the Enhyper Newletter, which was a weekly/monthly list of the links I found of note. I emailed this to about 400 people all over the world for a period of several years. These days I use del.icio.us which is pretty neat - but I still use the library occasionally to refer to articles which had seminal influence, like:

Bob Hettinga's Reading List for Financial Cryptographers - I bought most of the books and read them (yes - sad I know)
SET Grid - a comparison between SSL + Credit card and bearer cash - which is a simple but effective analysis of the advantages of bearer cash against SSL/Credit card transaction.

In Operational Research, the Maestro - Conductor of Multimedia Analysis Technologies paper taught me a lot about news analysis and multi-factor target identification.

One thing the tool taught me was that levels of hierachy are an average of 3-4 levels deep - with about 7 being the maximal. Something which is observable in some of the other KM tools I've been involved in over the years.

Anyway, there's around 1400 interesting URL's to browse - so enjoy.

Time for some Code - Shell Script Collection

I started programming in 1986 and largely owe my scripting expertise to Chris Bertin, who I believe works for HP. I found a script of his on a XePIX Gator-L on which I learned to program in C and Shell and it greatly inspired me due to it's technical content and beauty. So here's a collection of scripts which I've written over the years - you can find them on the Enhyper subversion server

There's some useful scripts - the biggest and most sophisticated is envbuild which automated a three day piece of work down to minutes. It automated the building of a sophisticated database schema and the underlying disk placement. There's some neat techniques in there - one where bc(1) is used to perform an iterative calculation of Informix data spaces.

Back to Basics in the Tier 1's?

There's a wind of change sweeping the CIty which I believe is being driven by the technology arms race. I'm beginning to hear rumours of the project manager culture being dismantled in some of the tier 1's - there seems to be a realisation that the people that matter are those who write code and deliver projects - not the project managers and paper architects which litter organisational structures.

The career path in a typical IB starts with graduate recruitment - which is a two year slog usually involving coding of peripheral functionality (if you're lucky) then jump ship to get more cash to another IB where you do more coding. But coding is hard and you need to get out of it so you buy one of those blue shirts with polo logo on it and a pair of chinos and hey presto - instant project manager. You spend your time in meetings and making technology decisions, lunching with the vendors, put on three stone in weight and develop a bad blackberry habit. You build teams, manage the politics and deliver what you think the business wants.

Deep down though, you know that the guys really controlling the show are the developers - they hold the key and you know it - so the last thing you do is let them talk to the business because as soon as they do - people will start to question what you do and boom - you're out the door.

It's an all too familiar pattern I'm afraid - but it wasn't always like this. When I started in IT back in 1986, Unix was rattling the cage of the mainframes. Everyone in software development at that time was competent scripters and programmers and the industry was quite small. However, back in the early nineties, I was the only guy sitting on the train with a computer book then I started to notice a lot of other people reading "dummies guide to whatever". This was the rise of the supply led consultancies who made a killing by overstaffing IT projects.

Suddenly everyone as getting into IT - this was the new way to make money. In reality, projects were delivered by small teams or even individuals. I remember working on one large project where I was the only guy in a team of 20 who could program - I delivered the whole data migration piece whilst the rest of the team wrote docs - an no, it didn't make me feel important - I just felt sorry for the poor client who was paying through the nose.

So the tier 1's are apparently making a strong effort to hire hybrid type lead developers - people who combine hands-on development / lead small teams and are able to run day-to-day delivery of projects. They want 'innovators' - something the consultancy led culture which still blights our industry seeks to deprecate.

If they're serious about hiring talent, then get rid of the non-programmers, abolish the title of architect and send them back to the coding front, replace project managers with tools which automate their function - tools like xProcess which builds the project plan in real-time and enables capture of processes so that you can do project estimation based on empirical data - not on invented deadlines.

Strategy for migrating to new messaging middlware

I was chatting to an old accomplice the other day who headed up FX architecture for a tier 1 in the US about my new position with 29West - apart from saying they were a great company with great tech, he said they has decided not to use the LBM product because of the pain of migration from the existing Tibco RV middleware. So part of my new role will be to create a migration path which is as pain free for our customers.

This is exactly the problem we had to solve in my current assignment (I don't start with 29West until late July btw) - how do we integrate Wombat (which runs over LBM) into an organisation which relies on another product successfully? The strategy we adopted was to use a straightforward design pattern to implement a piece of throw-away middleware combined with a touch of perception management - always important.

Project Evangelism Framework


As important as the technical feasibility and superiority of a candidate solution is the management of the change process. I've amalgamated some techniques which are based on open source tools, allowing debate and development of a community of interest around the solution. The idea is not new and was inspired by reading the Cluetrain Manifesto as a younger man.

Basically we have several chat channels - one for the project where the public can ask questions and get expert answers, one for the technology, so that we can fight our technollectual battles. A blog for a record of meetings, decision, vendor liaison and general project karma and lastly a wiki where we can disseminate project documents and build a support knowledgebase. I'll blog again about this as I have some theories about the roles people play which I'll elaborate.

Using this setup has surprising effects and advantages - meetings are now a matter of record for public consumption which modifies people behaviour towards cooperation and congeniality. Vendors are treated fairly and openly, decisions vindicated or challenged thereby using the wisdom of crowds. Project documentation is completed and of a higher standard. People behave more professionally. Business customers can see the real state of the project.

Technological Framework

First thing is to get the new infrastructure up to near production level on dev hardware with the minimum of fuss and footprint. Then productionise it so that there's autostart/stop, logfile monitoring and maintenance etc. Next you need to develop some examples or tailor the ones supplied to assist with onboarding.

It helps if you can develop the code to fill patterns of use within the organisation - this way the developers need minimum effort to integrate. Be ready to answer support from developers and sort out issues quickly. This way the community will begin to trust you because if you lose people early through poor infra, support of lousy code, it's going to be all the harder to get your new solution adopted.

You need to run the two infrastructures in parallel but new development needs to use the new infrastructure and existing code phased over to the new infrastructure once it has been proven.

To help here, I implemented daemon process which implemented a Facade/Proxy/Adaptor pattern. This can be written in whatever language you like, but I'd recommend C because it just so happens that it's the lowest common denominator. This allows you to take data from any source (databases, flat files, memory maps, MQ, Tibco RV, Emma, Vhayu, FAME etc). and provide it to the existing and new clients. In time, the new clients bypass the adaptor. This allows you to maintain the client functionality whilst developing new interfaces.

Fun with sort(1)

There are some unix utilities which give it a bad name - prime culprits are sed(1) - just read the man(1) page and you'll understand why. I think sort(1) is pretty abstruse too - I've been using it to manipulate log files which monitor market data info being pushed in and out of wombat.

The trouble with log files is that they usually are full of everything - which is fine if you have the time or patience to extract the information you require, however, now that we're shoving hundreds of trades through the algo system, this generates hundreds of thousands of log messages, I can no longer use vi(1) - the unix editor, to view them, as it runs out of space for the temp file. This mans resorting to all sorts of sed/awk/grep nonsense in order to extract the info we need. The criteria for this embryonic scriptette was to order entries according to a suffix alphabetically, then order numerically ascending within that suffix. Here's a script which does the job. The input data looks like this:

10:23:34.323 : 5 3, 2760.MAIN-EXC.Dx.LT {[1]=24 [2]=2 [3]=7360 [4]=36.730340 [5]=28.032340 [6]=2007-05-29 09:11:00Z}
10:23:34.541 : 6 3, 2760.MAIN-EC.DM.SS {[1]=24 [2]=1 [3]=7260 [4]=34.730000 [5]=28.000000 [6]=2007-05-29 10:23:34.095576000Z}

All 598344 lines of it. The first line sorts on the field "LT" and "SS" above and gives us a list of subsets that we need to process:

FIELDS="`sort -u -t '.' -k 5,5.2 MarketDataServer0.log | sed 's/.*\.\(.*\) {.*/\1/'`"

Now we create a file callled out

> out

for CODE in $FIELDS
do
sed -n '/.*\.'"$CODE"' {.*/p' MarketDataServer0.log | sort -n -t '>' -k 2,2 >> out
done

Then we cut out the entries for each "code" then pass them to our sort command which uses the > as a field delimiter and sorts numerically on the second field - ugly but necessary. No error handling or parameter passing yet - but this saves a whole lot of pain. Looks painful? sure but it's the sort of thing you just can't do on windows (well without Cygwin anyway)

Red Pepper and Coconut Chutney

Outside of the American psyche we have other programmer food than pizza which fuels software development - a lot of people who work in the Investment Banking community are addicted to curry and there's a good choice of hard core restaurants nearby like one of my favourites, the Lahore Kebab House. So as well as software wisdom, we'll be posting the occasional recipe - here's a start. This chutney only keeps for about a week in a cold fridge but is wonderful - if you can get it - use Kashmiri chilli powder for a more mellow flavour...

Ingredients

Two large red peppers (Bell or Capsicum)
Two teaspoons of roasted cumin seeds, finely ground
Two cloves of garlic
Two tablespoons of dessicated coconut
Half a teaspoon of salt
Half a teaspoon of hot chilli powder
Two tablespoons of water

Method

Dry roast the cumin seeds in a frying pan, colouring them to your taste, the darker the
roast, the stronger the taste. Grind in a spice mill or coffee grinder to a fine powder

Deseed the peppers and cut into small chunks suitable to put into a hand blender jug, then add
all the ingredients. Blend with a handblender and decant to a sterilised jar which should be refrigerated.

This is an excellent accompaniment to cold meats, dosas and any curry, particularly fish/shellfish.

OR49 Keynote Speech in the Knowledge Management Stream

I'm giving the keynote in the KM stream at this year's Operational Research Society Conference OR49 based on a stream of research which started about 8 years ago after reading a paper on newsgroup cluster analysis called telltale. Here's the abstract:

"It is proposed to summarise and statistically categorise multiple public and private information feeds to produce centroids directed by a combination of user constructed keywords and analysis of previously archived or disseminated knowledge. Social and physical networks will be extracted for temporal analysis and association projection. Comprehensive analysis of centroid relationships across sectors, categories and physical location will give a statistical event prediction capability and lead to the discovery of hidden relationships and associated events. End-users will construct a hierarchical keyword tree which will contain individual articles, summarisations, centroids or sets of related centroids. Users will also participate in a community of interest which they may form inter or intra-federation in order to disseminate emerging events or explicit knowledge. The system has applicability to financial market analysis, law enforcement and intelligence analysis."

This paper is the crystalisation of several themes and our experience into a system which we hope to build into an operational system. Many of the components already exist and over a series of articles I'll be discussing the philosophy behind the system. I'm joined on the enhyper blog by two experts in data visualisation whom you'll meet in due course. One is Dr Elie Naulleau from Semiophore. We'll propose how we can use the system for expert trading, algo trading and on the flip side, intelligence analysis.

Why Events are a Bad Idea (for high concurrency servers)

And Why Mixing Events and Threads is Even Worse

I've just been badly burned by mixing two paradigms - threading and events. All was working fine until the day before go live; the testers started to pour 400 stock baskets through the system rather than 40 which resulted in one of those issues which make your heart sink as a programmer. Between 5 and 15 stocks would go into pending which meant that there was a threading issues somewhere and it was go live that evening. Tracking it down was to prove difficult due to poor separation of duties between the threads resulting from the design having its origins as a single threaded, serial set of calls which took data from an event generated on one side and generated a modified message dispatched to the receiver and vice versa. In retrospect, the problem would have been solved by having single queue between the two threads, following the asynchronous put/take connector pattern. This would have ensured complete separation and higher throughput.

Mutex Spaghetti

As it happens, it was impossible in the time available, to redesign the solution and the simplest course of action was to go back, reluctantly, to a single threaded implementation. Time to test was a major factor here, however, not before some time was spent playing the mutex game. I started mutexing at a very low granularity which appeared to fix the issue (or break things completely) almost - I was down to one or two trades pending - which was not good enough.

Adding additional mutexes, it quickly became apparent that it's very easy to get in a mess either by blocking on an already locked mutex or by adding too many mutexes which means you end up in a mess anyway. After four hours of mutex soup - I made the decision to remediate the code back to single-threaded code. Performance, at the moment is not an issue.

So the moral of the story is look for a design pattern which fits your code - understand it and think the design through, we seldom have time, but if you can, use UML to build a sequence diagram - then you'll see the call chain and understand conflict between threads.

A friend of mine related the story of Sun's attempts to make the solaris kernel mt safe - this was a much harder task than they anticipated. Most of their effort was centred around protecting the key data structures rather and changing the programming paradigm so that users took the responsibility for data allocation.

Another pointed out an article on slashdot this morning "Is Parallel Programming Just Too Hard?" which raises some concerns which, as we can see from the above, seem to be valid. If you're going to write parallel threads, you have to spend time on the design - it takes three times the effort and you really need to use patterns, example code and sequence diagrams. I hacked it and got away with it - to a point. If performance proves an issue, and you can bet it will at some stage soon, then it will be back to the drawing board - and this time, the design will come first.

Interestingly, threading versus events is an interesting debate which this paper: "Why Events Are A Bad Idea (for high concurrency servers)" argues well and threading comprehensively wins the day as a paradigm over events. I've always been of the opinion that separation of duties via a thread is intuitively faster than event dispatch - this paper goes a way to prove my intuition right.

Finally, there's a well deserved mention for Functional Programming Languages such as Erlang and Haskell, which has much promise for multi-core programming as outlined in these excellent slides: Data Parallel for Haskell.

From CORBA to Command and Control Web Services

I was inspired to write a paper on "web services" back in 1999, when people in the banking community had heard of XML but had no idea what they could do with it. My inspiration had been the IATA protocol which I had seen used to automate the aircraft industry and heard rumours that the US Navys' supply line was also managed by these straightforward ascii messages which began with ZCZC and ended with NNNN.

I had just spent a couple of years boning up on CORBA - reading several books, trying to get a copy of Iona's Orbix product so that I could teach myself a new set of skills which would keep me fed for the foreseeable future. I liked the idea of CORBA - in particular the trader service - whereby you could look up a "service" and invoke dynamically. However, when I finally moved to a bank which could afford the technology - it was clear that all was not well. I had expected some form of centrally managed infrastructure and a set of services which I could use/add to. I wholly expected to find analytics (maths libraries) and a range of business "services" - instead I found a ORB on every desk. This meant that any solution developed would, in essence be, be standalone - thereby defeating any advantage of ORB technology. True to form, I discovered that it was indeed the developers who had mandated ORB technology, for the same reasons I had - career sustainment.

But this is not the real reason why ORB technology failed - the principle two were unreliability and complexity. You see the thing most banks don't tell you is that they use an awful lot of perl to "munge" data - perl is fast, quick to develop, easy to understand. ORB's on the other hand were developed by a small (in open source terms) team -who had a limited bandwidth - not quick enough to test the solution or fix the bugs quickly. To use an ORB for a solution costs money in licences, support and requires clever (i.e. expensive) programmers to implement. Once engineered, it was by no means performant - needing big metal to run - but the worst of all was the bugs - it just wasn't reliable enough for serious production use. Combine this with a long fix lifecycle and you'll understand why very few ORB solutions are to be found in any organisation.

So web services to the rescue - well - not quite yet - not that there's anything wrong with the techology - especially the security aspects. It has been possible to tunnel web services over ssh for a long time - combine this with X.509 certs and you have authenticated end points. No, the problem with implementing web services is mindset - people just don't understand the issues. Two of the most common complaints are security (see above) and verbosity (payloads increase by 30% - gasp!) This misses the point. The protagonists seem to want to design a web service that is meant to handle a substantial amount of data and be invoked repetitively. In the real world, web services should be used for command and control. The analogy of the data feed (i.e. comma seperated file sent somewhere for processing) still exists - only this way you have a way of programmatically orchestrating the solution inter enterprise - and that's what web services are all about.

References

[1] The Role of XML in Enabling Business Solutions Built from Collaborative Web-Based Services. Burnett, Papiani, Dec 1999

http://www.enhyper.com/content/iee_16_Dec_99_1.htm

Grid Computing Slowly Falls From Grace

I spoke at the The 451 Groups ECS Summit, London Regional Roundtable on Thursday, May 10, 2007 at the Brewery at Chiswell Street in London where the focus was supposed to be on Grid computing, the focus of much research by the 451 Group over the last year.

I noticed the trend in early 2006 that term Grid was losing it market appeal. It started disappearing from job titles, to be replaced by High Performance Computing (HPC) - this has now become mainstream with at least two IB's having the post. Another two trends were noted - data architecture is now high on the agenda and low-latency messaging is seen as the crucial to meeting the challenges of high transaction volumes.

So where's Grid computing heading? The general concensus were that the technology had not lived up to its promises in terms of performance and in particular: managability, security and lack of data architecture seemed to be the prime areas of concern. Grid in IB needs to grow up - in essence, despite the marketing hype, current grid offerings are little more than cluster computing applied to a few niche areas in IB such as CDO/CDO squared (btw check out www.cdo2.com - run by an acquaintance of mine - a real web service with real customers running on BLAST

The reality is that most jobs can be done now on multi-core, large memory machines. An 8-core/4 CPU machine with 64GB memory are a lot cheaper than an investment in grid - and you get a lot of processing power now for not a lot of cash. Nodes can be chained together with 1GE nics and switch to produce an effective HPC cluster and you can either use your own threaded app with memcached or have a play with jini.

BP's Black Swan

BP's Black Swan

I was happy to discover Nassim Nicholas Taleb's new book waiting for me when I arrived home yesterday evening. Although I've recently been experimenting with vignettes like this mini-blog entry (I'm standing on the train, scribing with my thumbs, so please forgive any errors or incoherence), I think I'd rather have something to read.

I heard an interview with the author on Econtalk this weekend and ordered the book on Sunday. Very nice service from amazon, if a bit pricey.

Recently there has been some indignance, mostly from the yellow press, alleging that Lord Browne had callously decided £10m to be the value of a human life. I suppose some would say that human life is priceless, but this conveniently ignores the fact that industrial accidents do occur, and they have a financial impact that must be considered.

More to the point is that BP's analysis of the likely consequences of an industrial accident was an utter failure. The reason for this grossly uninformed statement takes us back to the subject of Taleb's book: the vast majority of industrial accidents result in little or no loss of life. A large firm collecting data on the impact of these events would reasonably expect that a large explosion in a major refinery in a wealthy industrial centre to be quite unlikely. So unlikely, we can be fairly sure it was unanticipated, in spite of widely available reports of dangers at the affected plant site.

I am sure this sounds improabable to most people. Why would a large company look purely at a statistical model to account for risk, and ignore the widely-reported concerns of their employees? From a purely technical perspective, it's all just data.

The crux of the matter is that most risk models based on statistcal assumptions are (for lack of a better word) wrong. They assume that the probability of an event occurring in the future can easily be derived as a function of past occurrences. Even if the concerns of employees could be quantified in a meaningful way, the risk calculations would become intractable.

So maybe the indignant voices have a point after all. Putting too much faith in mathematical models is foolhardy: many improbable events are more likely than can be forecast, if only because they've never happened in the past. While the black swan is maybe a tired example, it's easy to understand.

More on Taleb's book once I've actually read it...

Cognitive Dissonance

My current definition of cognitive dissonance comes from reading the Economist's Style Guide on the way in to the office, and Communications of the ACM on the way home.

With some effort, there is some meaning to be extracted from the latter journal, but the violence impressed upon the English language by the computing profession is severe.

I know I am a victim of this social phenomenon. The Style Guide informs us that the "online community means geeks and nerds". I take exception to this, but given my colonial education in science and engineering, I am poorly equipped to explain why I am neither a circus performer who bites the heads off chickens nor a character in a derivative American sitcom.

More serious is the droning language describing initiatives in information technology to obtain an understanding of the role of new technology and its systemic impacts of automation, notwithstanding the achievements we have heretofore achieved regarding the human impacts (CACM March 2007, p. 37).

With all due respect, I say WTF?

The state of information technology is confusion and crisis, as it has been for the past 30 years.

How do we fix it? How about if IT practitioners (we aren't professionals, thank goodness) start saying what they mean and meaning what they say?

The software crisis is a crisis in human communication. Let's move out of this state of perpetual war and see if we can make some progress in this industry.

STEP - An aid to IT Recruitment

It's increasingly difficult to vet prospective employees due to the ever increasing complexity of the technology market and its burgeoning list of skills and experience. STEP was developed in order to cope with a large volume of applicants and a very poor hit rate of applicant reaching interview stage.

It is lightweight process which is quick to learn, requires no software to implement it and leaves a lasting record. As such, it can easily be pushed down to the recruitment agent, enabling them to filter candidates prior to client selection saving you time and effort.

Current Practise

There are a variety of "soft" processes used by recruitment agents to find candidates for roles in IT. These range, at the lower end of the market, from simple keyword searches to more process-orientated practices at the higher end.

Keyword matchers who work search for a skill, get hundreds of results then choose the first twenty or so who answer the phone. At the higher end, a common assessment mechanism is a "balance sheet" which consists of a spreadsheet-based form gathering vital statistics plus a SWOT (strengths weaknesses opportunities and threat) analysis of the candidate. The former performs poorly due to its random nature, the latter is subject to personal prejudice of the agent which is less than ideal when it comes to recruitment at the significant salary levels at the higher end.

STEP aims to improve on this by applying some basic analysis of four key elements which are the cornerstones of an IT career: Strategy, Technology, Evangelism and People skills.

STEP Overview

STEP is a practical tool to methodically assess curriculum vitae as to their suitability for specific roles and can be used to both recruit staff and to find employment in the Information Technology field. It has been tested in the field successfully with, arguably, good results.

STEP is applied to both the role profile and the candidate's Curriculum Vitae and therefore can be used to match candidates to roles.

Skills/attributes are categorised into four areas: Strategic, Technical, Evangelism and Project management/People skills. To each of these areas an experience level (low, medium and high) is associated.

In analysing a role profile or CV, each statement is analysed and given a STEP rating. For a role, the STEP ratings are then aggregated to provide an overall STEP rating. With a CV, positions are analysed in chronological order. Within a position, each statement is given a STEP rating and aggregated for that position, then finally aggregated to produce an overall STEP rating.

Also, in the case of a CV, a line is drawn between positions indicating if the job "chains" together logically - in other words, logically follows on from the last position. If there is an unusual job move, the line is marked with a cross to indicate that the interviewer should investigate further should the candidate progress further.

Additionally, for each position, a notional "trajectory" is noted against each. Trajectory is the analysts view of whether the position was an improvement from the last position. This may be in terms of expertise, financial or a combination of intuitive factors. These are then graphed temporally to give a heuristic view of career progression.

The aggregated STEP rating for the candidate can then be used for selection of appropriate roles and vice versa.

IT Industry Overview

The IT industry has attracted people from all walks of life and with diverse experience, many who do not have specific IT training but have rather used their innate personal skills to fashion a career, rather than an aptitude for technology.

Whilst good project managers/consultants are highly valuable, those with vicarious technical skills and experience only serve to make the recruitment process significantly more difficult.

Traditional Assessment Methods

Traditional methodologies for role/candidate matching staff such as certification testing assess only the candidates ability in passing tests, rather than how good a fit they are for a specific role. This has led to many "book" based engineers who lack the experience to engineer solutions. One notable exception is the Red Hat Certified Engineer qualification (RHCE) in which one is armed only one's talent to pass the test. It is renowned for its robustness and inability to be passed by reading books alone.

The traditional incumbent authored tests concentrate too much on the writers specific skills and are marked subjectively to be of any genuine use in the recruitment process.

To address these issues, STEP analysis provides a methodology to assess both the role and the application and thus can identify matches before the human process starts. It is easy to understand and apply and provides genuine organisational benefit.

How to Perform a STEP Analysis

Categorise

Start with the role profile - tag each requirement with one of the following categories and the desired expertise level sought:

- Strategic

Design/implementation of cross department/divisional/enterprise/global community initiatives which require architecture, product knowledge, scalable, resilience, standards etc.

- Technical

Any hands on use of technology: modelling, programming, infrastructure engineering, network design etc.

- Evangelism

Managing change - pushing an idea into the organisation/community, whiteboarding, presenting etc

- Project/People

Project management/people skills - managing staff and deliverables, dealing with ambiguity and conflict etc.

Expertise Level

Assess whether the level of expertise demonstrated was Low - Medium - High

Aggregate

Add up all the occurrences until you get one figure for the role profile:

S m-l
T m-h
E l
P l

Above is an example of what one might expect for a programmer.

Apply the same criteria to the candidate's cv - go through each paragraph/bullet point and allocate a category/level. Aggregate for each position and finally aggregate the positions to compare with the role. This will give you an idea whether the candidate approximates to the role.

Role Chaining

Roles should follow on from each other in a logical way. Sudden changes in career direction should be investigated further.

Role Trajectory

This involves placing an arrow beside each role indicating which direction the candidates career was progressing. Some interesting traits were observed which on examination indicated either a ceiling of ability had been reached or a lack of direction or a motivation to accept further responsibility.

Ideally, one would expect a steady progression overall although an interesting observation was that career progress tended to jump in steps linked to age. A common pattern was a steady rise followed by a period of similar roles, usually short term. This is the signature of a contractor/interim employee selling a particular skill.

Conclusion

Overall experience in using this methodology was positive in that it enabled me to deal with complexity in measured and open way. The job chaining highlighted career anomalies such as lack of focus or considerable drive.

The methodology was particularly useful in eliminating candidates who had principally soft or people skills combined with vicarious technical experience.

No posts since Friday the 13th, 2002? I feel impressed to post something significant.

Unfortunately I don't have the time or talent to compete with this Economist briefing (apologies if it's behind a subscription firewall - let me know and maybe we can work out a fair-use provision). It is a great primer for those of us wondering where we are sitting in the brave new world of innovative credit products (spoiler: nobody's quite sure).

http://economist.com/business/PrinterFriendly.cfm?story_id=9033348

It's hard to have an opinion about that, other than to say it reaffirms my decision to stay out of the London real-estate market.

The BBC, on the other hand, is much more likely to elicit a somewhat less than politic opinion, as they point out a fascinating and topical archaeological find:

http://news.bbc.co.uk/2/hi/uk_news/education/6584011.stm

Seems that a bunch of hunter-gatherers (sons of Abel? where are the farmers?) were caught out by a bad spot of global warming about 8,000 years ago. Now given what I've come to believe about human nature, I would claim that these folks were just as likely as we are today to blame human hubris and interference in things beyond our ken for the ills that befall society.

Yet another reason not to buy beach-front property in London.

[Enhyper Financial Crypto Library] News for 13-Sep-200

Web Services Links & Resources(added: 6-Sep-2002)

http://wsindex.org/

Researched directory of internet resources for .NET and XML Web Services

The Information Hiding Homepage(added: 9-Sep-2002)

http://www.cl.cam.ac.uk/~fapp2/steganography/index.html

fabien a. p. petitcolas's Digital Watermarking & Steganography Homepage.

Thirty Years Later: Lessons from the Multics Security Evaluation (added: 10-Sep-2002)

http://domino.watson.ibm.com/library/cyberdig.nsf/papers/FDEFBEBC9DD3E35485256C2C004B0F0D/$File/RC22534.pdf

The bottom-line conclusion was that “restructuring is
essential” around a verifiable “security kernel” before
using Multics (or any other system) in an open environment
(as in today’s Internet) with the existence of well-
motivated professional attackers employing subversion. The
lessons learned from the vulnerability assessment are highly
applicable today as governments and industry strive
(unsuccessfully) to “secure” today’s weaker operating
systems through add-ons, “hardening”, and intrusion
detection schemes.

Strange Attractors and TCP/IP Sequence Number Analysis (added: 12-Sep-2002)

http://razor.bindview.com/publish/papers/tcpseq.html

We consider the problem of inserting a malicious packet into
a TCP connection, as well as establishing a TCP connection
using an address that is legitimately used by another
machine. We introduce the notion of a Spoofing Set as a way
of describing a generalized attack methodology. We also
discuss a method of constructing Spoofing Sets that is based
on Phase Space Analysis and the presence of function
attractors.