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.