Well, I was invited back to London to visit the client. It was an early start at 5.30 and I was on the plane by 7 waiting for the 7:25 takeoff.

It didn't happen.

Because of winds, Heathrow was increasing the intervals between inbound flights. Ok, I wait, I had some slack built into the schedule. Oh what fun it is to sit for an hour on a plane that wasn't going anywhere.

Finally we took off at around 8:30 local time and we arrived somewhere in the vicinity of London then we started flying in circles. It seems that a plane was stuck on a runway so Heathrow was down to 50% capacity at its peaktime.

Another hour goes by and we land.

I then spend time trying to leave messages with the 'virtual' consultancy that I'm a little delayed, but should still get to their office, a room in a business centre shortly before the interview. They tried to call me back but somehow managed to ignore the message that I left giving the UK mobile number I was using and calling me on my German number which I had swapped out.

I arrived, had to wait for the guy who was going with me to the interview. No problem, we did arrive on time but the end-client was running rather late too and had just got back from a US trip and was clearly not quite with it yet (he hadn't even seen my profile). We had a good chat and things seemed to go ok, although not ringingly well but it became clear that the project would almost certainly overrun the six months discussed and probably run for a year or so. The project had elements in the UK but also it would mean frequent trips to the US. Think of the air-miles, but think of the dead-time whilst your distant forebearers are examined for suspicious Arabic sounding names in the immigration queue at JFK. Note, there are many ways of transliterating non-Latin symbols such as Arabic to Latin. The dept of homeland insecurity has problems unless you are a terrorist with a western name, in which case you will probably be invited to the Whitehouse.

Anyway, having just been reminded of the joys of a long distance commute, I wondered whether I really wanted to do this every week.

With just a few minutes debriefing in the taxi with the sales person responsible for the client, I then left for a quick bit of shopping and then went for a chat with another test consultancy with a bank as a client.

Goodness, these guys actually had a real office, a converted warehouse on the edge of the city. This did give a little more confidence so we chatted about a comparatively short project. This seemed more positive if only for the reason that it gave me the opportunity to decide not to stay in London if the commute was getting me down.

I eventually made my way back to Heathrow for my flight back. I was a bit edgy as I was there only about 40 minutes ahead of the flight (minimum) so I hustled through security (this time it detected my watch).

Why did I bother? It appears that Lufthansa's checkin system, the weight balance system and something else important had died because the mainframe had been taken down to have some new hardware added. It was brought back up, but the OS didn't see the hardware because some important patches hadn't been applied. Guess which airline I was due to fly back on?

I wandered terminal 2, waiting. Many airports are proud of their functional architecture where they look something like the Pompidou Centre. Departure gates not being considered functional are somewhat harder to locate. The sign-boards announced the original departure time, a "Delayed 1 hour" remark, but after an hour went by, the board wasn't updated (you would normally expect a gate at least thirty minutes before). Anyway, I finally located the correct gate to find that the flight had only just arrived at the new departure time, so there would be another half an hour while it was turned around.

Eventually, I reached Frankfurt about two hours later than planned and absolutely exhausted. I still managed to drop by on the leaving do for the agent who got me into my last two contracts. I think this is something like the third one that he has had in the last month, so I didn't hang around for more than an hour or so.

Luckily, I had a holiday planned for the next week where I could relax a little while wiating to see how things panned out.

Well the last day of my contract came and things were very quiet. It is quite possible that the project as a whole will be effectively canned because of a manager. So, I could be the first of many to go.

Anyway, along came an interview, but in the UK and I had to get there the next day and pay part of the cost. You can fly anywhere with an open budget, but you try doing no-notice short-haul in Europe and it can get very complicated but a colleague tells me it is still possible to cross-book tickets. And it was.

It was a beautiful day in London which makes it seem somehow easier to return. On the other hand, one must be realistic and expect a large number of not so nice days (i.e., cold, wet and windy) if I take on the project. Money doesn't go far here either so yes, you are paid more but it goes so quickly compared with other places. The rate should just about cover a weekly journey home and leave me almost as much as I earned before so all is not lost.

The other problem is that with a long commute and living away, slowly I should consider upgrading my notebook PC which has about 30 secs of battery power (yes, replaceable) and a not very fast 500MHz processor which can't be upgraded. The new job does include US travel so perhaps I can do something about getting a machine there.

I noticed the last 100 or so tests that I had sent to a BA/team leader have sat in review for the last week. This guy is normally quick, does he know something we don't? Anyway a big meeting had been scheduled for today to find out.

I arrived today to find our offshore vendor, a big one based out of the Carribean parceling up their documentation into binders. Not a good sign.

With all the aplomb of a teenie-bopper singing "whoops, I did it again", the project was announced as suspended and the external vendor was disengaging. This isn't a new thing here, few major projects actually get seen through to completion. Perhaps the bank could look at their project methodology here?

The external vendor can't be completely blamed in this case, they did produce late, but the specification was woolly as hell and almost no documented requirements. Not good when you have developers at a centre in Manila, a long way away from the business knowledge.

The real problem is deeper. If your developers are more than 10 minutes away, you really, really do want to have the requirements and specifications cast in stone. On a large system, you really want to get the architecture delivered first and then build upon that. Ideally, get the architecture done inhouse and then just outsource smaller sections of code even to multiple vendors.

Maybe they will restart the project. Amongst other things, this handles client reporting for the banks - something which is extremely important and a legal requirement. Without the new system the bank, a major one, needs to resort to paper. Oh dear!

Yes, our very own offshored/outsourced project is busy going through the motions of dying. It should be noted, that this is not an instantaneous change of state, rather something long, drawn-out and rather painful to watch.

So due to the extended delay before anything can be delivered, the entire external QA team is being 'iced', as there is nothing to test (I'm quoting management here). Actually there is quite a pile still from one of the bits being done onshore, but it is fairly obvious that although the offshore vendor has overrun by over 100%, they have had to cut us back to fund the overspend. After all, QA isn't important is it and they are now far too dependent on the offshore developer to change now.

Of course, the real worry is unless they can show something for all the money already spent (about $14m), the project will get canned. If they can show something (and there is no effective QA to declare it rubbish) then they may be able to fool someone into further funding.

Of course, this could be the strategy, deliver something that doesn't work, use the fact to beat the developer over the head and get the price cut and then fix everything during an extended beta.

Lets just hope that they can find and fix all the bugs. This system looks after serious money.

A concerned parent usually makes enquiries of any new baby-sitter to determine whether they are responsible enough to handle a job or whether they will end up ignoring the baby and enjoying the family alcohol supply with their boyfriend instead.

When you hand a project to another organisation, it is important to ensure that the company is appropriate for your project. That is, that it is big enough to handle the project and it has a track record.

One interesting factor is the experience. When a person has done something, they have physically participated at least. When a company has done something, then at best you can say someone who was an employee at the time did it. There may be little transfer of knowldege so the expertise is lost. Sometimes the staff turnover may be so high that the experience is actually lost during the project. Given the high ratio between the fees charged by some offshore companies and the employee compensation, staff loyalty becomes an issue.

Of course, it is good to know that you are dealing with a sound company. It is difficult enough in the west. Worldcom or Enron anybody? Remember that companies pay taxes based on their annual reports, and in some lesser developed countries or the former Soviet Union, those taxes may be very high so they may well be creative works of art compared with the reality.

In general, it is better to use your eyes and ears when investigating the suitability of an outsourcing company, particularly when it is offshore. Also remember, that when an outsourcing company pitches to you, they are unlikely to use just average staff and the staff you see are unlikely to ever work again on just implementing projects.

We have the word Downsizing which means to get rid of all the people that do but leaving management who are now in a quandary because they don't have anyone working for them.

Nevermind, this leads us to the solution: The word Outsourcing now which means essentially sending work to be done elsewhere for the price of a cleaner here. Then we have the word Upskilling which means that our offshore result has actually provided us with cleaners and we now want programmers which will cost us more and take longer. Finally because the project has ran out of time and money, we have the word Descoping which means agreeing that "being taken to the cleaners" by the offshore company is now accepted with the realisation that the solution doesn't meet the original requirements.

Offshoring works, however only within certain parameters. On a recent project with which I have had the pleasure of being involved, the offshore resource being provided by one of the big consulting companies produced about 46% of what was expected and about 34% was tested according to their own standards. In common with many outsourcing projects, we have been told that the project will succeed no matter what. The business remains blissfully unaware of the problems and in the end will have no option but to accept what has been given to them. In the end, the quality issues will be addressed by Deskilling and Outsourcing of the entire test process.

Note that outsourcing can work, however, you must expect senior staff to spend a large amount of time supervising the projects and training the staff. Unfortunately, as the offshore staff become more skilled they want to improve their income standard so they move around. Expect at least a 50% staff turnover. Then there are communications issues. Even if the offshore staff are working on-site, straight-forward concepts may need considerable explanation. Pure coders are few and far between these days and any kind of analyst/programmer must have an overview of the process that is being implemented.

The last point is that your business processes become embedded in the code. If you are lucky, the code may match the documentation, but it only starts this way. After successfully outsourcing and offshoring your operation you may find that the only people who know your business processes aren't working for you but for someone else.

At this point it becomes advisable to close up shop and move offshore yourself.

When there is more process sitting outside the company, the business is likely to follow!

When you design a large system you take information about what the business wants and you convert them into something that a programmer, who may know little about the business can implement. As the audience for the specification document is technical, full of wonderful things like UML, we can't expect the business to understand it. This is why it is very useful to capture requirements in a form that the business can understand and sign-off.

Of course, the real issue is that when the business receives the software, they are reasonably certain that the system is attempting to implement what they wanted.

Pretty obvious? How come I'm on a massive project for a major German project with no formal requirements. It appears that the scope of the system was decided by SMEs (Subject Matter Experts) and the business analysts at meetings which were not formally minuted. How do we know if it will ever work?

A long time ago, I had Samba working quite happily in a Windows NT 4.0 Domain. Since then, I had changed the domain server to Win 2K active directory and wanted to Samba my gateway system (192.168.0.1), which is running Linux. Samba 3.0 now has support for Windows Active Directory Services (ADS) and some (limited) documentation.

At least the gateway system is running Linux now. In a previous incarnation it was running 2K as a backup domain controller (with the same address) and it had since been reformatted and Linux installed.

That was the problem. The PDC thought that the gateway system was still running as a BDC but was playing stupid. Unfortunately, I couldn't use another IP address for the gateway system and lacked the patience to reinstall Windows 2K.

The usual Active Directory GUI didn't allow to wipe out my old BDC without consulting with the BDC (which only existed on a backup). After some Googling around and fighting with Microsoft's hopeless search facility, I finally found something called Ntdsutil.exe or something which allowed me to wipe out the BDC.

Still no luck, Samba just couldn't get hooked up with my PDC. I eventually found out that the PDC still thought that the gateway system was a Windows box. This needed some further puring of the PDC's DNS. Note that a Win2K Server PDC really wants to have its own DNS.

Yes, I got the old rubbish cleaned off the PDC and the systems started talking. However browing the Samba system from Windows resulted in the Windows desktop crashing.

Ho hum, all in an evening's work!

The UK, or at least England and Wales, has the longest continuous history of patents in the world, with the earliest being crown licensed monopolies in the 15th Century. The earliest was granted in 1449 by Henry VI for the supply of stained glass windows, which was a new technology then.

The link of patents to inventions didn't happen until James I, who then enacted a law containing the words:

"for the term of 14 years or under hereafter to be made of the sole working or making of any manner of new manufactures within this Realm to the true and first inventor"; such monopolies should not be "contrary to the law nor mischievous to the State by raising prices of commodities at home or hurt of trade".

However, the early patent system had many problems (including the need to get a separate Patent for Scotland). Trouble over Arkwright's loom and Watt's steam engine in the 18th Century established that an idea must be specified in a practical way and that improvements to a patented idea were themselves patentable.

I have no problem with the principle of patenting something physical because it is possible to place two inventions next to each other and compare them. However as we get more abstract then it becomes a lot more difficult. How do you test an algorithm for similarity? Well, the answer to that one is in court and there are plenty of lawyers who will argue the hind legs of a donkey at $300/hour. It becomes simply too expensive to defend the patent in court unless you happen to be a major company.

Another problem is that the 20 year patent term is inappropriately long in a rapidly growing field such as IT, so the released patent does not benefit the public good as was the intention. Indeed, a patent can be a major barrier to progress - think what would happen if Tim Berners-Lee of CERN patented the idea of a web browser?

I have been given the task of maintaining a package that is fairly important for my client over the next 6 months. They have known the package will be replaced for the last two years so it is being run in a low-maintenance mode.

The problem is that many of the developers/maintainers have now left and we are left with a mountain of C/C++ code and a few pages of documentation. This is not easy. Design reverse engineering tools are out of scope unless they are free so I just have to fight it.

Luckily, most of the time it works. However, someone always wants just one more little change.

Some very intriguing snippets are slipping back from that little contretemps that is happening in the Middle East. It appears that the war in the middle east is proceesing somewhat slower than expected.

The military of the coalition has some excellent equipment, but it already appears to be needing some maintenance. Some of the captured soldiers were from a maintenance battallon.

One wonders how long equipment can last in these conditions before it requires overhaul, particularly with sand-storms as well.

The Iraqi equipment seems largely ex-Soviet. The Soviets designed stuff that can be used from Tundra to Desert, and almost everything imbetween. Someone once told me that it was reliably unreliable, but very quick and easy to maintain.

One of the organisations that I have worked for and with is a major electronic financial products exchange. Their host systems have been sitting on Alphas running VMS and have been since they transitioned off the VAX. As load has increased, they have normally just bough new hardware with only relatively limited architecture changes. Software changes carried risk, hardware changes within a hardware platform carried a minimal risk - so they just bought the latest model.

Unfortunately the Alpha is dead. The last model is the Alpha EV78 and then OpenVMS will be running on the Itanium, at least that seems to be what HP, the owners of Alpha and partners with Intel for the Itanium are promising.

When Digital introduced the Alpha, it took several years before it was seen to be reliable enough for use as a cluster server. It took the exchange even longer before they converted their application. Not because the application was hard to port, but more because the app was pushing some bits of VMS very hard and it certainly could find the weaknesses very easily.

The first Itaniums are out, but the word is that they are slow. Speed was never an issue with Alpha, but these babies start out with problems. A bad sign. VMS doesn't run properly on Itanium yet (it is past first boot, but that is all so the rumour goes), so I guess the conversion to Itanium is at least 5 years ahead. The app is currently very dependent on VMS but can't be stretched across large clusters due to the interaction between the individual cluster nodes. Scalability becomes an issue.

What to do about performance then, no new Alphas and a useful Itanium is a way away? Time to bite the bullet and do a rewrite?