Saturday, 27 November 2021

The Great Conference Room Naming Débacle

It's very common to give names to meeting rooms. Often, the rooms in one building will be named according to some common theme. In one Cisco building I worked in, the theme was "elements". The room nearest my office was called Arsenic. Quite why, given a choice of 120 elements, they chose one that instantly brings to mind nasty murders and agonising death, only the Facilities Department would know.

Another building named its rooms after cocktails. My nearest room was called Kamikaze - presumably whoever chose the name had spent more time drinking than studying recent history. It did attract some wry comments from my Japanese colleagues who visited there.

No Cisco buildings had rooms named after individual aircraft, like "Wright Flyer" or "Spruce Goose" - maybe because there aren't that many famous ones. Had they done so, Enola Gay would surely have been selected. It would have been the perfect place to close that city-wide broadband deal with the mayor of Hiroshima.

There was a DEC building I visited once that named its rooms after famous computer scientists. That sounds reasonable, except that several of them worked for DEC at the time. Wandering around you would see a room labelled Butler Lampson or Leslie Lamport, and think, I had no idea he worked here.

Which brings me to the topic of this post. In the early 80s, DEC's UK engineering team was growing rapidly. At first they tried to house us in a warehouse that was surplus to requirements, in Acre Road, Reading, next door to the UK importer of the disastrous Yugo cars. They did a cheap and nasty conversion into office space, which was woefully inadequate. The building was impossible to heat anyway, but installing a hot-air system that vented near the roof didn't help at all. As a result, everyone had a little electric heater under their desk. They also forgot to install extra power to run all the servers, and the electric heaters made things worse. Everything was so delicately balanced that one day a colleague arrived and turned on his 60 watt desk light - and the whole building went dark and quiet. After that they did install extra power.

In 1983 we finally abandoned Acre Road and moved into luxurious new digs called DECpark II, adjacent to the recently-built UK headquarters. It was specially designed to accommodate engineers, with dedicated labs and computer rooms.

There were 18 meeting rooms scattered through the building, and they needed names, a job which fell to the facility manager. He was a pompous and disagreeable individual, who drew attention to himself by driving to work every day in a Rolls Royce. It was agreed that the theme should very aptly be famous European engineers and scientists. The pompous facility manager organised a competition to name them, asking everyone to come up with their own list of 18 candidates. The candidates who got the most votes would be selected, and the entry that came closest to the final list would win a bottle of champagne. All very jolly-japes.

Unfortunately he'd forgotten he was dealing with computer scientists, with their usual delight in finding ways to break carefully designed systems, and to embarrass people in authority. One of our number, Mike, had already shown himself to be especially gifted.

This was in the first blush of the Hitch-hikers' Guide to the Galaxy's fame. When we were first connected to the corporate DECnet, it was Mike who had ensured that we got DECnet area number 42, and then gave all the systems names from the series - VOGON (later famous as the source of the Vogon News Service), SLARTI and so on. Then there was FORTY2, whose DECnet address was 42.42.

Later another pompous new senior manager showed up. He wanted a dedicated system to house all the secret information that only important people were allowed to access. (Though I was one of the privileged few, I never did find out what he had in mind). Mike tried to call the system ARKB, and very nearly succeeded. (For those who don't remember HHGG, Arkb was the spaceship that took all the telephone sanitizers, timeshare salesmen, HR consultants and other indispensables, and abandoned them on another planet).

Mike, with a little help, quickly figured that if all the network engineering team submitted the identical list, we would be sure to win - we made up about a third of the total staff. Better yet, we would get to decide the conference room names. The team set to work selecting all the rudest, most obscene and generally inappropriate names they could find. The only one I remember was the German scientist August Kundt, famous for Kundt's Tube. I'm sure you get the idea.

Mike distributed the list and we all submitted it. What the pompous facility manager should have done, of course, was to say, "Nice try, guys" and perhaps give us a bottle of champagne. But he was too pompous for that. He sent an angry rant to the whole facility and to our US management, and tried to get Mike fired. He completely failed to take into account that Mike was far more valuable to us than he was. Nobody liked him much to begin with, and after this he was reduced to a laughing stock. He didn't last long, and was soon replaced by someone less pompous but unfortunately even more incompetent. And, needless to say, we never did get a Kundt Room.

Saturday, 13 November 2021

Peter Gibbon, RIP

I just learned that a very old friend of mine, Peter Gibbon, passed away a couple of years ago. We were very close back in the 80s, but we lost touch when I moved to the US in 2001 and I'd only seen him once since then.

After he retired, about twenty years ago, he spent most of his time working for a record company. It was on their website that I learned of his death. There is a long obituary, a series of very touching articles written by people who worked with him there. I knew him a long time before that. It seems worth setting down some memories of a very special person.

I've written elsewhere of my involvement in the OSI standards for open networking, starting in 1980. That was where I met Peter, and for over ten years after we would find ourselves together in numerous fairly exotic locations, sharing excellent food and drink, tedious meetings, and many long and enjoyable conversations. He worked for IBM, where he was an expert on their networking products (SNA). I was never quite sure what his "day job" was, when he wasn't attending standards meetings. I think he was a sort of ultimate level technical support for IBM's important customers, which is to say every Fortune 100 company in the world. Since DEC (my employer at that time) and IBM were major competitors, we didn't talk much about our jobs within the companies.

The OSI standards were made at ISO, the International Standards Organization. Technical input came via the national standards bodies - BSI in the UK, ANSI in the US, AFNOR in France and so on. So to participate in the meetings, I had to attend meetings at BSI in London and present my company's input there. This was where I first met Peter. The meetings were typically in the morning, at BSI's offices right in the centre of London, in Mayfair. It was a very old-fashioned place, where tea-ladies would bring round urns of stewed tea at 10.30, accompanied by digestive biscuits. After the meeting we would adjourn to the Marlborough Head a very short walk away, and drown any remaining disagreements in good English ale. Though the BSI meetings were universally good-tempered, even when the disagreements were deeply fundamental, as with the network layer architecture controversy.

Peter was first and foremost a gentleman. He was always impeccably dressed in a suit and tie, as IBM demanded in those days. His voice, with its subdued but unmissable Oxford accent, invariably commanded respect without being domineering. When he raised his hand and said "Mr Chairman..." you knew that what followed would be worth listening to. Yet his origins were in the north of England, in Burnley. If you listened carefully you could just pick up traces of that accent as well.

He was always someone you wanted to have in a meeting. Even if you disagreed, he would find a way to compromise and make progress. I don't remember anyone ever getting frustrated with him, at least not openly. He was also a brilliant note-taker. In those days, before laptop computers even existed, everything in a meeting was written by hand. Peter's handwriting was as impeccable as his costume. I can still see it in my mind now, though I doubt I could find an example, instantly legible and, more important, always exactly to the point.

The one phrase that most comes to mind is, "Mr Chairman, perhaps I could draft some notes for discussion tomorrow?". No meeting chair could refuse that offer, especially not from Peter. Next morning everyone would receive copies of his impeccable handwriting, capturing precisely what he wanted the meeting to have said, just close enough to what was actually said that it was impossible to debate. It was sheer genius.

One of our first trips together was also one of the most extraordinary. In 1983 China hosted an ISO meeting. Now, meetings in China are commonplace, but this was probably the first time they had hosted an international meeting on a technology subject, ever. It was in Tianjin, about 100km east of Beijing, in those days a filthy coal-mining town. Everything was covered in millimeters of greasy coal dust. My clothes never recovered from the trip. The trains that carried the coal away from the mines were all pulled by giant Soviet-designed steam engines belching black smoke.

Among the many things Peter and I had in common was a love of trains. Steam trains had long since disappeared from British or American railways, so a chance to see them in action as routine daily transport was not to be missed. We made several visits to the main railway station, once we figured out how to get there. On one of these we very nearly got arrested for taking pictures.

Our meeting was in a giant conference complex outside the city centre. It had been badly damaged by the Tangshan earthquake in 1976, and only one huge building remained usable. It contained our hotel rooms, the dining facilities, and the meeting rooms. We weren't really expected ever to leave the premises, though there was nothing to stop us. We shared a love of buses, too. Peter quickly worked out that the number 1 trolleybus route passed outside the complex and ran straight into the centre of town. These ran about once per minute, meaning that there was always one at any stop, and often two or more. We were fascinated by them, and forever after would refer to something that was amazingly frequent as "like the Tianjin number 1 trolleybus".

Peter liked things to be very organized. In Tianjin he got quite distressed when one of the bus routes was diverted around some construction work. Neither of us could read Chinese, so figuring out where we were was an exercise in decoding scribbles. "Number four with a hat on" was a character which occurred often - much later I learned it meant "west".

After the meeting, we had the opportunity to go on a tour of China. Peter and I visited Hangzhou, Shanghai, Suzhou and Guangzhou, before finally returning to Hong Kong. We had transport adventures together in each place. In Suzhou we went out for a long walk and miraculously managed to catch the last bus, or so it seemed, back to our hotel, a rattling, ancient thing that jangled along at about 15 miles per hour in exchange for our fare of about one US cent each. Very typically, Peter managed to find a bus timetable for each city we visited, and then seemed to learn it off by heart.

In Shanghai we just happened to be there on the Chinese national holiday. Our hotel was about 3 km from the waterfront - the "bund" - and the broad streets to get there were packed tight with people celebrating. There were buses, but they could barely move. We walked there, had a beer in the Peace Hotel, and then made our way back through the throngs.

Conversations with Peter were fascinating and effortless. If he knew anything at all about a subject he knew everything, or at least a lot more than anyone else. He didn't make a big deal about it, he didn't rub your face in it, it's just the way he was. We talked about transport in all its aspects, we talked about our work together on the OSI standards, and we talked about just about anything else.

He had an amazing capacity for detail. This comes through in the Ace Records obituary, but it wasn't just music and records. He knew everything about every single one of the ex-LMS locomotives from his childhood. "Oh, 43219," he'd say. "That had the experimental Throgmorton injectors from 1949 to 1954. So did 43336, but that never entered service with them." He wasn't showing off, he never did that. He just knew all this stuff.

Whenever we got a chance, we would go to transport museums together. We took the long, long suburban train ride out to Ome in the distant suburbs of Tokyo to the Japanese National Railway Museum (now moved to Omiya). We went to the railway museum in Sydney, where Peter turned out to know everything about every locomotive in service.

Our meetings were often hosted in Washington, DC. Peter had an encyclopedic knowledge of the restaurants and bars there. He would take us to somewhere exotic - I remember an Ethiopian place where, unusually, at the end of the meal you ate the tablecloth. Then it would be off to a bar somewhere, often followed the next morning by a spectacular hangover. He knew one place whose speciality was the B52, an evil layered cocktail that nobody would even try unless they were already pretty drunk. On one occasion we managed four of them each. How we got back safely, I have no idea.

He had an intimate knowledge of Washington's geography, which is more than you can say for the taxi drivers there. Taxi rides with Peter were an adventure. He would sit fuming at the bad route the driver had chosen. "If he'd just taken D Street and turned left on 14th, we'd have been there ten minutes ago." 

Peter's facial expressions were extraordinarily expressive, once you knew him well. On this occasion his face said "this guy is an idiot". I have few photos of him, but there are a couple here.

On the one where he is alone, his face says, "This is complete rubbish, and you just keep digging a deeper hole, but I can't even be bothered to argue with you." Or in vernacular, "yeah, whatever" - though Peter would never have said that. It was taken in a public area of our hotel in Tokyo, the Shiba Park, where we would sit and drink beer from the vending machine until the small hours. (We called it "Lois's Bar", but that's another story). I think Peter has already had two or three in this picture, to judge from the angle of his tie.

On the other photo, he is with a group politely applauding some formal speech. His face very clearly says "How much longer is this going to drag on?"

Dinners were generally group affairs with the UK delegation, half a dozen people at a time. Getting that many people to agree on a restaurant is near impossible. The discussion would go back and forth over a couple of beers. "I had Chinese last night." "I don't fancy Japanese." And so on and so on. Finally Peter would declare, "We're going to so-and-so" and off we would go. Wherever we went - Tokyo, Sydney, Seoul, Berlin, anywhere - he had food guides, actual paper books. This was long before TripAdvisor or indeed the internet. By the third night he would get frustrated. 

"I am not choosing the restaurant tonight," he would declare. "You can decide yourselves for once." He would sit on the sidelines with his "how much longer will this go on?" face as the group trashed every suggestion anyone made. I didn't even bother participating, because I knew how it would end. After fifteen minutes Peter would pull a disgusted face and say, "OK, I can't stand this any more, we're going to such-and-such." And off we would go.

In 1986 we had a meeting in Berlin, while it and Germany were still divided. We decided one evening to go train-spotting in the East, figuring there must be a lot of trains there. We crossed the border at Friedrichstrasse, an adventure in itself. We stood in a long line, then our passports were meticulously checked. Peter had grown a beard (the only time I saw him with one), which wasn't on his photo. That slowed things down a lot. They didn't really want westerners there, but they brought valuable foreign currency. We made the ritual exchange of DM50 or so, then continued our journey.

We re-boarded the S-Bahn to the Hauptbahnhof (main railway station). Absolutely nothing was happening. There was one train scheduled to leave in a couple of hours, and that was it. Peter had - of course - chosen a restaurant, supposedly one of East Berlin's finest, on Alexanderplatz. We shared a table with another couple, a mother and her son in his late 20s, but didn't talk to them. Then at the end of the meal the son introduced himself in excellent English. They were Czech, as was the restaurant. Peter started to get nervous. He'd once hinted at some peripheral involvement with the security services, and could clearly see "Stasi entrapment" writ large. Then our new friend started to criticize the way the Russians ran East Germany - "What right does some Ivan in Moscow have to tell the Germans how to live their lives?"

I swear that if Peter could have hidden under the table, he would have. We left as soon as we could and scuttled rapidly back to Friedrichstrasse and freedom. Peter could breathe freely again.

On another trip to Berlin in 1991, after the wall came down, we took the S-Bahn out to the former East Berlin airport at Schoenefeld. It made quite a contrast with our previous trip. The train ran straight through, no lengthy customs formalities. We sat drinking coffee in the terminal, watching the ancient Russian airliners that still operated there.

Since his long-suffering companion Mickey is no longer with us either, I think it's safe to mention one of the biggest things that happened in Peter's life. When I met him he and Mickey, still married, lived a very tidy suburban life somewhere in Hertfordshire. Not long after, in about 1983 or 84, on some trip somewhere, he met a woman who changed his life. She was a doctor, a specialist in something very exotic. She was obviously an amazing woman, though I never met her. If she and Peter were to be believed, she did odd jobs for various national security services as well as her day job in one of the major London hospitals.

Peter was head over heels. He followed her all around the world as she travelled to conferences and such. He and Mickey split up - I rather think she told him to go and work it out of his system, and come back when he was done. That was when he bought the little house in Staines where he lived for the rest of his life.

I think the relationship was always very one-sided, probably the one time Peter's somewhat obsessive personality let him down badly. It fizzled out within a year or so but it was a lot longer than that before Peter could put it behind him. And when he finally did, Mickey was there for him. She had already moved somewhere close. For a long time they lived separately, though I understand they remarried much later on.

He was in Singapore with his new love and took her to one of his favourite places, the Victoria Garden outdoor food market. He had taken me there too, a fabulous place full of tiny market stalls selling every kind of food you can imagine. Unfortunately on this occasion he ate something he shouldn't have. He returned with three distinct tropical diseases, each of them extremely nasty. He spent a week in the Hospital for Tropical Medicine in London - a place best avoided because you're just as likely to catch something even worse while you're there. Mickey was there for him - one of the few occasions I met her, when we both visited him there.

Peter was an amazingly good friend. At one meeting, in Guernsey, I had a very difficult time running the meeting, thanks to an especially disagreeable delegate. Afterwards I was fuming. Peter shepherded me to dinner at one of Guernsey's best restaurants and kept me company while I worked off my frustration. I remember that at the end the waiter, very solicitous, asked if we would like some port. "Can I get a pint?" I asked, still needing calming down. The waiter and Peter both laughed. I didn't get a pint of port, but the next morning was difficult.

He was always helpful to everyone. He was very aware of the problems of non-native speakers in meetings like this. Brits and Americans unintentionally use all kinds of jargon and slang that leaves others in open-mouthed incomprehension. Peter would take the time to explain in simpler language or to rewrite convoluted paragraphs.

In 1988 my own life turned upside down, when I met the woman who changed my life. For three years I lived on my own, not far from Peter - my partner was in France, and it took us that long to figure out how we could live together. I saw Peter a lot more often. After BSI meetings we would often spend the afternoon chatting, then go down to Staines to spend the evening. One damp February day comes to mind. We had a drink or two at Peter's local, across the street, then it was time for dinner. We walked up and down the high street, but every single restaurant was full. Only when we got back to Peter's house did we realize it was the 14th, Valentine's Day. Dinner was something pre-cooked from Peter's freezer, warmed up in the microwave.

My partner and I had also met attending the same ISO meetings, so she and Peter already knew each other. We married two years later, carefully timing it so we could spend a short honeymoon in Bangkok on our way to an ISO meeting in Sydney. Peter was undoubtedly the organizer of the amazing reception we got there from our friends and colleagues. We were both chairs of our respective groups, and one of the presents - surely chosen by Peter - was a pair of matching gavels which we still have.

My last OSI meeting was in San Diego in 1992. Peter was there, of course. By then I had finally moved to France, and had no professional involvement with Peter any more. I saw him from time to time on trips back to England, but it wasn't the same as being together for two weeks at a time. After I moved to the US in 2001 I saw him very little - just one more time.

In 2013 we celebrated my 60th birthday in England, with family and with all the old friends we could muster. Peter came along, with Mickey. By then his arthritis had become a big problem. He could walk, just, with a stick and some help. It was wonderful to see him again.

Despite all the time we spent together, I never knew anything about his early life. I'm not even sure what he studied at Oxford. I know nothing about his parents, though I recall that his mother was still alive back then. He just wasn't interested in talking about himself.

This has turned out to be rather long, but it is still only a tiny fraction of all the memories of our wonderful times together. Peter, we all miss you, wherever you are. I hope there are lots of records and lots of trains, and a staggering amount of detail to learn about all of them, wherever it is.

Tuesday, 21 September 2021

Moving my Plane and its Pilot to France

Sierra in France, about to leave Toussus-le-Noble


When we moved to California in 2001, I started learning to fly. It was something I’d thought about for years, and in the US it was easy and relatively inexpensive. I got my private pilot license in early 2002.

I bought my own plane in October 2002. I spent a lot of time thinking about what I should get. I decided on a Cessna TR182. The 182 is the Swiss-army-knife of planes, with decent speed, a good payload and range, easy to fly and easy to maintain. The TR182 version adds retractable gear, making it a bit faster, and a turbo, allowing it to fly easily at high altitudes. I found a decent 1980 example at a local dealership. It came with the registration N5296S, and quickly gained the name Sierra, after the last letter.

My friend Bill, who got me started as a pilot, wondered how long I would keep it - apparently the average length of plane ownership is about 5 years. But 20 years later, we’re still together. Sierra was in decent shape when I bought her, for a 20-year old plane. The avionics were OK but I soon upgraded them to what was then state of the art - a Garmin GNS530 radio/navigation unit, and a GTX330 transponder that could receive information about traffic in the vicinity. Later I had the interior redone, in cream leather which even now looks very nice.

Sierra and I did a lot of flying together, especially in the early days. With Isabelle, we often went somewhere over the weekend or just for the day. On one occasion I flew her to Denver and then to Leadville, the highest public airport in the country. Flying over the Rockies makes the value of a turbo very obvious. On the way there I made one of my few excursions into the flight levels, at 20,000 feet. (In the US these start at 18,000 feet, though in Europe they are much lower.)

By the mid-2010s, the paintwork was getting tired. A long life parked in the open at Palo Alto, next to the seawater bay, had produced some nasty corrosion. It was time to undertake the repaint that I had been thinking about for a long time. I went for the original orange and brown colours, and a design fairly similar to the original too, though modified to allow for a full-size twelve-inch registration. The colours are “so 1980s”, but any other colors would be tied to a time too. Back when I first started thinking about the repaint, burgundy-and-grey were very popular (along with strange squiggly lines). By now that would look just as dated as the original colors, and even less suitable.

Soon after the repaint, it was time for an engine overhaul too. With that done, I had a 40-year old almost-new plane.

The Move

In 2019 we decided to move back to France. It was something we’d been planning, in an abstract way, for several years. Finally all the circumstances came together. One obvious question was, what to do with Sierra? I certainly wanted to carry on flying back in France. Flying is a bit of a drug, and very hard to give up.

I’d flown in France, and the UK, several times before, though not for a long while. From my own experience, and from following various Internet forums, I knew that it was a very different experience from flying in the US. Everything is more constrained and rule-bound, and a lot more expensive. Instrument flying, especially, is a lot more limited - there are fewer approaches and you have to pay to use them. I really wasn’t sure what ind of flying I’d end up doing.

Essentially I had three choices:

1. Sell Sierra, join a flying club, and fly club planes. The problem with this is that flying clubs in France generally have only a handful of aircraft, sometimes just one. Taking a plane for an extended trip is out of the question, so I’d be limited to local bimbling around.

2. Sell Sierra and buy a plane in Europe. This seemed like a good idea until I asked on European pilot forums about it. Everybody said it was a bad idea. Maintaining a French-registered plane is much more complicated than an N-registered one. Also, I’d want to buy something substantially newer than Sierra, now over 40 years old, so it would mean investing a lot more money.

3. Take Sierra with me. This isn’t without its own complications, as you’ll see later. But it meant I could keep the plane I know so well. And in the worst case, I call always sell her in Europe.

There was variant of number 3. I could leave Sierra in the US, get some experience in Europe, and decide what to do later. But planes need to be flown. I looked into putting her on the rental line at a club. The club head’s prognosis was uncompromising. “Your plane is old, it’s a turbo, and it’s retractable. The question isn’t whether someone will damage it, it’s just how long it will take. Don’t do it.” That left arranging with friends to fly her from time to time, but that could quickly get complicated too.

There are two ways to move a small plane like Sierra across the Atlantic. The obvious one is to fly it, starting at Goose Bay in north-eastern Canada, then via Greenland and Iceland to Wick in northern Scotland. For Sierra, this can be done without even installing extra fuel tanks. But it’s a risky flight - if the engine stops, you’re in the near-freezing north Atlantic, with minimal chance of survival even wearing a full waterproof immersion suit. I wasn’t keen on this, and my wife was even less keen. There are professional ferry pilots, who do this for a living. I got in touch with a company, who quoted me nearly $40,000. That is getting on for half the value of the aircraft, and not realistic.

That left the other solution, which is to unbolt the wings and put everything in a shipping container. Then, when the container arrives in France, the wings are reattached, and the plane is good to go. At least, that’s the theory. I found someone nearby, at Hayward airport just across the bay, who does this for a living. They quoted me $9000 for the dismantling, packing and shipping. There would obviously be some costs at the French end too, but it would be a lot cheaper than ferrying.

The surprising thing about their quote was that it included absolutely nothing about what would happen when the plane arrived in France. Their plan was to ship it to the container port at Fos-sur-Mer, near Marseille, and that was it. I’d assumed they would be in touch with a network of shops at least in major countries who could finish the job, but evidently not.

Fortunately - so it seemed at the time - through the Internet, I had made contact with someone at my destination airport, Cannes-Mandelieu (LFMD), who seemed perfect. She was an FAA qualified mechanic and inspector (IA) as well as being both a French and FAA instructor. She agreed to take charge of the reassembly, and would also be ideal for getting the French pilot qualifications I would eventually need.

Arriving in France

Sierra at Hayward, waiting to be shipped

On Monday 15th March 2021, I dropped Sierra off at Hayward airport, meeting for the first time Ed, who ran the shop there. His office was full of exhibits and artifacts going back a very long way - he told me he has been doing this for over 40 years. I was joined there by my aerobatics instructor friend Rich, who had agreed to drive me back to Palo Alto. Ed regaled us with tales of the various aircraft he has shipped over the years

The rest of our move was a long and incredibly stressful tale of bureaucracy, packing and dealing with the movers. Despite my worries and all the sleepless nights, everything ended up going smoothly. Two days later, on 17th, we set off for San Francisco airport, with our cat Missy, seven huge suitcases and as many items of cabin baggage, for the one-way trip to France.

As far as Sierra was concerned, there was nothing to be done until she showed up in France. The original estimate for that was six weeks - two weeks for the dismantling and packing, and four weeks for the container to reach France. That turned out to be extremely optimistic. Nearly three months passed before I even got a confirmed date for the shipment. The shop attributed this to Covid and the difficulty of getting hold of containers. For sure, all shipping worldwide was a big mess - there were articles about it in the media.

I wasn’t bothered by the delay. We had far more than enough to occupy us with the household move, once that container showed up, at the end of May. It would be the end of July before we had (mostly) finished unpacking and organizing things at our new home in Nice.

In early June, Ed sent me the shipping information, with a planned arrival at Fos-sur-Mer on 20th June. Now it was time to get serious about the French end of things. But it turned out not to be so simple.

The mechanic who was supposed to take care of reassembly suddenly became increasingly hard to get hold of. She didn’t return emails, and when I called her she would be busy, promising to call me back - which she never did. She did ask me, reasonably enough, for some information about how Sierra had been packed into the container. But communication with Ed was even harder. He also failed to return emails or answer the phone. The one time I did manage to get hold of him, I had to squeeze every word out of him. The only information I could get was “you’ll need a fork-lift with extra-length forks”. That seemed reasonable enough, and I passed this information on to the mechanic.

Ed had also managed to tell me the contact for the shipping agent in France. Fortunately they were extremely helpful and responsive. Finally the container arrived at Fos. It would take a few days to clear customs and then be delivered by road to Mandelieu.

That was when my mechanic dropped her bombshell. “We’ll be able to do the reassembly at Mandelieu,” she said, “but it’s your responsibility to get the plane out of the container.” WHAT? I have absolutely no idea how to do that, and I’m certainly not going to teach myself fork-lift driving skills in the process.

Enter my friend Laura. I’d met her on the internet very early on when trying to figure out the move. She’d shipped her own Carbon Cub from the US to France a year earlier, and gave me lots of useful advice. I sent her a despairing message late at night, when I got the message from the mechanic. She responded instantly, giving me the contact information for Michael, who had taken care of her plane.

At 9 the following morning I called him, naturally speaking French. After a couple of sentences he said to me, “You speak English, don’t you?”, and I realized he’s American. “Of course I’ll take care of your plane,” he said. We had a deal. I can’t even begin to describe my relief. To store the plane in the container while I searched for another solution would have cost something like €100 per day.

Naturally he wanted to know a bit about how the plane had been packed. I tried to get in touch with Ed, at Hayward, but got no response at all. Michael tried too, but to no avail. Finally he sent me a message saying, “Sorry, was in a car accident, but I’m fine now.” I hope he is, but that was the last we ever heard from him. Michael just had to improvise when it came to extracting Sierra from her container.

I had to call the importing agent again. Michael’s shop is at Toussus-le-Noble, one of the few GA airports in the Paris area. It would cost me over €1000 more to move the container from Fos to Toussus, but there was no choice. One little twist was that the container made the journey by rail - making Sierra one of the very few aircraft to have travelled by train. I was told it would take at least a week, because of all the congestion of container traffic.


Then on Friday, I got a message from the importers. “Please pay your bill immediately so the shipment can take place. Is the mechanic ready to receive the container on Monday morning?”

Well no, he wasn’t. I’d told it him it would take at least a week. I called him. “Sure, Monday is fine,” he said. On Monday morning he texted me a picture of a huge container truck. “On my way to work, got stuck behind this!” he said. And indeed it was my container. Later that day he sent me more pictures. It was wonderful to see Sierra again, even if she was still a long way from being flyable. He extracted her form the container with no difficulty and sent the truck back on its way, avoiding any storage charges.

Sierra's container arriving at Toussus-le-Noble

It turned out that the packing had not been done very well. The fuselage was resting on the bare wood of a pallet, with no packing at all, and the gear half-retracted. Surprisingly, this had caused little damage, just a few cosmetic scratches on the belly. As the reassembly progressed other damage showed up. They’d cut through a couple of cables when they removed the wings. They hadn’t noted the position of the critical camber-adjustment cams when they removed the wings. They’d damaged some bits and pieces of the landing gear. Nothing that couldn’t be fixed, but irritating.

I agreed with Michael that he would do an annual at the same time, since it would soon be due, and left everything in his hands.

A couple of weeks later I was able to meet him. He was visiting Mandelieu and invited me to lunch and to meet the people he knew there, which turned out to be extremely useful. He’d flown down from Paris in his Aerostar, a sleek, fast piston twin. It’s one of the few small planes where you have to worry about the 250 knot speed limit below 10,000 feet. Afterwards I visited the FBO where Sierra was to be parked and maintained, meeting the people there.


There’s a saying in aviation that no aircraft can fly until the weight of the associated paperwork exceeds the weight of the aircraft. This wasn’t quite true for Sierra, but there was a lot to be taken care of.

The first hurdle was customs. Normally an import like this would have to pay VAT - 20% in France, quite a lot of money. But because it was part of our belongings returning to live in France, it ought to be exempt. Laura had been a big help with this, and among the vast quantities of baggage we had brought with us was every document I could find which would support it, including 20 years’ worth of receipts for parking and taxes at Palo Alto. It wasn’t enough, though. The importers wanted the original purchase receipt from 2002. Getting hold of this, or at least a copy of it, was quite a challenge, but fortunately it worked. The shipment cleared customs without a hitch.

The next problem was legal ownership. It comes as a surprise to most people that you can operate a plane in France with a US (N) registration - like N5296S. If we’d managed to import our Toyota FJ, for example, we would have had to re-register it in France within a few months - which is the main reason we didn’t. Probably over half the privately owned aircraft in France, and Europe generally, are on the US register, and flown by pilots using their FAA licenses. The ongoing bureaucracy associated with European registration is much more demanding than the US. Also it is pretty much impossible for a private pilot to obtain an instrument rating in Europe, so if you want to fly IFR the obvious route is an N-registered plane and an FAA IR. The European authorities hate this, and have taken steps to control it, but it remains true.

Still, without US citizenship, I cannot legally own an N-reg plane outside the US. Fortunately this is a widespread problem with a well-known solution. There are companies that specialize in providing US ownership via trustees, keeping everything legal. Following recommendations on the web, I got this set up without too much difficulty. In the US I’d owned Sierra through a Delaware Corporation, and the cost was similar. (That also created some worries over the duty-free import, but it turned out not to be a problem).

Finally I had to get European insurance. This worked out to be bit more expensive than in the US, but not a problem. In the US, it’s insurance companies who really decide what you can own and fly. If as a new PPL with 100 hours you go out and buy a sophisticated retractable, you simple won’t be able to insure it. In Europe this seems to be less of a problem. For example when I added Michael to the insurance, so he could do post-maintenance test flights, all they wanted to know was his total time. Nothing about time in model, or retractable time, which would have been a major issue in the US. When I added an instructor to my US insurance, they wanted not only time in model but time in model of the same year, which is ridiculous.

Flying in France

Although I can legally fly my plane in France without any formalities, it seemed like a good idea to get some experience operating in France and also with using French on the radio. This isn’t required for ATC, who will work in English, but it’s needed if you ever go to uncontrolled fields, and it seems like a good idea to be able to do it even with ATC. Also, from May 2022, a French license will be needed for residents even when flying an N-reg aircraft with an FAA license. The good news is that they have invented a simplified procedure for getting one, for experienced pilots, but still it has to be done.

We planned to stay at our “beach house” near Biarritz, while we waited for our possessions to show up. I’d flown a long while ago with the Aéroclub Basque at Biarritz airport, so I contacted them, but they took a long time to respond and when they finally did they weren’t very encouraging. One time, years ago, I’d stopped by the club on the airport at Dax, and when I got in touch with them they were much more helpful.

Their first requirement was for a French medical. I made an appointment with an aviation doctor nearby. In the US the system is pretty much self-policed. If you can walk unaided into the doctor’s surgery you will probably get a medical, as long as you haven’t declared anything the FAA doesn’t like - which is pretty much everything. On the other hand, if you omit so much as a dental hygienist appointment from your declared list of medical treatment, you can be banned for life from holding an FAA license. This makes the self-policing work quite well.

The French doctor actually examined me, which was quite a shock. I did a hearing test, a vision test, an ECG, a respiratory capacity test, and various other things. Luckily it all went well, and half an hour later I left his surgery clutching a French medical certificate.

My first flight at Dax was in a Robin DR400, the universal French aeroclub plane, which had been modified to fit a 100hp Rotax engine. The nice thing about the plane is that everything seems brand new. The not-so-good thing is the 100hp engine, which makes climbing a delicate matter and limits it to a top speed of around 85 KIAS. Still, I’m not in a hurry to get anywhere. We flew to Biarritz, not far away, and did a missed approach since otherwise we would have to pay the €40 landing fee. That’s another big difference between the US and Europe - in the US only truly huge airports, like SFO and JFK, have landing fees. At an equivalent of Biarritz - say San Luis Obispo - you pay nothing. Then we returned to Dax via the beautiful Atlantic coast.

Dax is a strange airport. I don’t know its history, but now its main role is as the training base for all official French helicopter pilots - army, police and so on. There is fleet of about 20 identical red-and-white H120s based there, and during the working day there is a constant background noise of helicopters. It’s controlled by the military, and civil flying is permitted only for the aeroclub and the small handful of based planes. You can’t just go and land there.

The other odd thing about Dax is the runway. The actual paved surface is 800 metres (2600 feet) - about the same as Palo Alto. But trees just off one end limit its useful length to 494 metres, about 1600 feet and definitely the shortest runway I’ve ever used at a designated airport. Landing on 25, the usual runway, you spend more time looking straight down at the treetops 100 feet below you, than you do looking at the runway. The airport is closed at night, and you can understand why.

I’ve done several more flights there, getting to know French airspace and regulations, and practicing French on the radio. I speak French fluently, almost bilingually, but still the first few radio interactions were just as panic-inducing as the first few flights in the US. Now I can generally get by OK, but if ATC goes off-script I can still be left completely lost. There’s always the option to switch to English, but that seems like a bit of a defeat. Occasionally it happens that ATC hear my accent and reply in English anyway, which is kind of annoying.

An oddity of French aero clubs is that the instructors work for nothing - bénévole in French. This makes no sense to someone used to the US system, where you pay $50-100 per hour, but that’s the way it is. Most of my flying has been with Pierre-Alexandre, a trained airline pilot, who but for Covid would now be flying for Ryanair or Wizz. He’s staying current and filling in time by instructing at Dax, but in order to eat and pay the rent, he works in a sandwich shop in the mornings!

I also managed one flight with an instructor in a 172 out of Cannes. We did a tour of all the named VFR reporting points around the airport, which was extremely useful. I’d hoped to fly some more, but between holidays, aircraft availability and other hiccups, I didn’t.

Named reporting points are another non-US difference. In the US, there are reporting points around airports but they’re informal. At Palo Alto you can report Lake Elizabeth, Cement Plant, Cooley’s Landing and numerous others. The only way to get to know them is to fly locally. If you fly to an unfamiliar airport and they tell you “direct Joe’s Tire and Muffler” you have to say “unfamiliar” and hope they’ll come up with something less cryptic. In France every airport has a “VAC”, a combined approach chart and airport information sheet. For bigger airports this will include several named reporting points which are used when arriving and departing. Dax for example has S, SE, N, N2, NE, BG and more. Luckily SDVFR knows about these, because some of them are pretty obscure if you’re trying to identify them by ground reference.

First Flight

Our route from Toussus to Mandelieu

Getting Sierra ready to fly again took a long time. There was, as expected, a constant string of little things that needed fixing, and then there was August - when the whole of France, including Michael, disappears on holiday. Finally, at the beginning of September, we agreed that I would pick Sierra up on Monday 6th. This was subject of course to weather - I certainly wasn’t going to fly a recently-reassembled plane in IFR, and with zero IFR experience in Europe. The previous week I’d signed a contract to park and maintain Sierra at Mandelieu - necessary since otherwise I would have nowhere to park when I got there.

Luckily the weather was good. A pilot and CFI friend of mine had agreed to come along as moral support, and practical support if necessary. We took an Air France flight to Orly, and a taxi for the half-hour ride through the leafy southern suburbs of Paris to Toussus. Finally, I saw Sierra again, just one week short of six months since I left her at Hayward. She looked perfect.

Michael gave us a tour of his hangar. His speciality is rebuilding damaged Piper PA46 Malibus, of which there were several cadavers around the edges of the hangar. Two of them had been damaged at the same airport, the very challenging “altiport” at Courcheval. We went to lunch at the on-field restaurant, where I finally met Laura - she’d agreed to join us there. It was all very enjoyable, swapping flying stories. She had worked in the Bay Area for a time, and flown out of Palo Alto, so we knew a lot of the same people there.

We did a short post-maintenance test flight together. Everything seemed fine, though we forgot to test the autopilot, which turned out to be a mistake. I surprised Michael by rolling into a 60 degree bank - quite forgetting that not everybody has aerobatic experience. Toussus is a tricky airport. It’s right under the 1500 foot floor of the Paris airspace, which is absolutely closed to VFR. It’s also hemmed in on three sides by the surface region of the same airspace, so it’s a bit like flying in a blind tunnel. There is one route out, and the same route back in again.

I’d been worrying over the preparation of the flight for weeks. French airspace is extremely complex. There is military airspace everywhere. Some of it is permanently closed, but most isn’t. All my French pilot friends told me, don’t worry about it. Plan a straight line, you’ll nearly always be allowed in, maybe with an altitude change or a slight detour. Michael had quite literally flown in a straight line from Cannes to Paris after our meeting there. But what if they don’t let you in? What do you do then? Finally, with the help of the excellent SDVFR app which understands all the subtleties of flying in France, I’d worked out a route which would let me avoid all military airspace, including all the stuff that would probably be inactive. It also avoided flying over any seriously inhospitable terrain, like the Massif Central. The actual route was Toussus - Rambouillet - Pithiviers - Nevers - Moulin - Montelimar - a few kinks around stuff en route - Cannes. I had to choose the right altitude - 7500 feet, no higher or lower.

Finally at 4pm, two hours later than I had intended, we took off. Despite all my fears the flight was completely uneventful. I soon discovered that the autopilot didn’t work, mysteriously since Michael assured me it had been fine in ground testing. It was quite enjoyable to hand-fly a long flight for a change. The first hour was over the rather dull agricultural plain south of Paris, under a perfect blue sky. As we got further south we started to see a few clouds, though nothing you couldn’t fly around. We also started to see terrain - we were within gliding distance of the Rhone valley, but underneath us were the rolling foothills of the Massif Central.

The town of Montelimar is famous for two things: fudge, as immortalized in the Beatles song Savoy Truffle, and its VOR (radio navigation beacon). Whenever you fly from London to Nice, the pilot always comes on to the radio about 30 minutes out and says “we are just approaching Montelimar”. Why this little insignificant place rather than say Lyon or Avignon, you ask yourself. The answer is that the VOR there is where the flight will turn left towards Nice.

We did the same, but then we realised that despite the perfect weather forecast, there were actually some clouds. We dropped down to 7000 feet, and then by stages to 5000 - still comfortably above the terrain, though not what we’d planned. Our route took us over the vines of the Cotes du Rhone, and later over Cotes de Provence, and just north of the highest mountain the area, Le Mont Ventoux at 6600 feet.

Clouds over Le Mont Ventoux

We’d been talking to someone for the whole flight. France makes a distinction between control and “info”, which is a VFR-only service. Sometimes they’ll hand you off to someone, sometimes they just say “squawk VFR” and leave you to figure out who comes next, though they will tell you if you ask. Generally working in English was fine, though it took me several attempts to get Marseille Info to understand who I was. That seems a good argument for using French.

Finally we reached the first reporting point for Mandelieu, WL, and were able to call Cannes Tower. They gave us a straightforward arrival - thank goodness for my one recent flight there. We taxied to my brand new parking spot, after 2h45 of flying.

And that was it. We left for the Atlantic coast again a couple of days later, leaving Sierra in the hands of Jet Azur to finish up the few remaining squawks. Now I have to figure out where we want to fly to, when we get back.

First Landing at Mandelieu

Wednesday, 23 June 2021

Kotlin for a Python and C++ Programmer

A while ago I got interested in Kotlin as a possible type-safe alternative to Python for our system. A lot of the non-performance-critical things are done in Python. As a lot of people have discovered, Python works well for small programs. But small programs have a tendency to get bigger, and to take on a life of their own. Maintaining large Python programs is hard, and refactoring them, for example to change the way objects relate to one another, is just about impossible. You're sure to miss some corner case which will show up as a runtime error much later.

Our CLI was the obvious candidate for experimenting with Kotlin. This is several thousand lines of Python and predictably, it has become hard to maintain. My first efforts with Kotlin were not very successful. It is based on Java and inherits some mis-features and design baggage from there, which stopped me from doing what I wanted. Also, the build environment is a nightmare.

Then recently I took another look at this project, and saw a way around my previous problem. As a result, I have since written a complete Kotlin implementation of the CLI. It's a nice piece of code and much easier to maintain and work with than its Python equivalent.

Here's a summary of the good and bad points of Kotlin, based on my experience.

  • Really, really good: the Kotlin language. It's a delight to use with lots of features that lead to compact, uncluttered code, yet totally type-safe. More on that later.
  • Very good: the IDE (called Idea). Intuitive and easy to get used to, and makes writing code just so easy. Only problem is that it occasionally crashes, taking the system with it.
  • OK but not great: libraries. Like Python, Java supposedly has libraries for everything. But finding them is hard, and figuring out how to use them from Kotlin is even harder.
  • Awful beyond belief: the build system, a dog's breakfast of several different tools (Gradle, Maven, Ant, who knows what else). As long as you stay within the IDE, life is mostly good. But at some point you generally need to build a stand-alone app. There is no documentation for how to do this, and what you can find online is confusing, contradictory and rarely works. Probably if you come from a Java background all this seems normal.

Idea: the IDE

Kotlin is joined at the hip to its IDE, which comes from the company that invented the language (Jetbrains). The same company also produces PyCharm for Python, and the two are very similar. It's everything you could ask from an IDE. The instant typing-time error checking has spoiled me completely, and now I expect Emacs to do the same when writing C++ - except of course that it doesn't.

The biggest problem, running it on Ubuntu, is that every so often it freezes and takes the entire GUI with it. If you can log in from another system, "killall -9 java" kills it and allows the system to keep going. Otherwise, you just have to reboot.

It does a good job of hiding the complexities of the build system, as long as you want to stay entirely in the IDE. But the problem with anything "automagic" is what happens when it goes wrong, or doesn't do what you need. The build system is a nightmare (see later) and the IDE offers no help at all in dealing with it if you want to create a stand-alone app.

It sometimes gets confused about which library symbols come from, and flags errors that aren't there. It still lets you run the compiler, so it's only a nuisance. It also isn't very helpful when you add a library that comes from a new place. You have to hand-edit an obscure Gradle file, and then restart Idea before it understands what you have done.

The Language

Once I got my head around it, Kotlin is the nicest language I have ever used. It particularly lends itself to functional-style programming, but there's nothing to stop you using it like C or Fortran. The few irritating things are a result of its Java legacy - fundamentally, Kotlin is just syntactic sugar over the top of Java. Some of the really nice things:
  • inobtrusive strong typing: everything's type is known at compile time, yet you rarely have to be explicit about types. The compiler does an excellent job of figuring out types from context, like auto in C++ but much better.
  • ?. and ?: operators: between them these make dealing with nullable values very clean and simple. ?. lets you write in one line what would take a string of nested if statements in C++ or Python. 
  • lambda functions: all languages now support lambda (anonymous) functions, but in both C++ and Python they're an afterthought, and it shows. In Kotlin they are an integral part of the way the language is meant to be used, making them a very clean and natural way to express things.
  • the "scope functions": a collection of highly generic functions that make it easy to do functional programming. For example, the 'let()' function allows you to execute some procedural style code using the result of a functional call chain. 'also()' makes it very easy to write chainable functions.
  • generic sequence handling functions: 'map()' does the obvious job of applying a function to every element of a sequence or collection. There are plenty more that simplify all kinds of common requirements, for example to trim null elements from a list after some processing.
  • string interpolation: the string "foo = $foo" replaces the last part with the value of foo, converted as appropriate to a string. That started with Perl and is now available in Python 3. Kotlin takes it further though, allowing complex expressions and figuring out the string syntax, e.g. "foo = ${x.getFoo("bah")+1}".
  • extension functions: it's easy to define new functions as if they were member functions of a class. They can only access public members of the class, but to the user they work exactly as if they were part of the base class definition. For example I wrote a function String.makePlural() which figures out the plural of a noun. This has always struck me as an obvious improvement but it has never even been considered for C++ (nor Python as far as I know).
There's nothing really bad about the language. The "generic" support is fairly feeble compared to C++ templates. In C++ a template parameter type behaves exactly as any other type, for example you can instantiate it. And no validity checking is applied until you instantiate the template, which is very flexible.

Kotlin's generics are built on the Java equivalent. You have to specify exactly what the template can and can't do in the function definition, meaning you can't for example write a numeric function using the normal arithmetic operators. (It doesn't help that there is no common supertype for integers and floats that supports arithmetic). Once you accept this, it's not too hard to work around it. But it's a shame.


The great thing about Python is that you can find libraries to do just about anything. The same is supposedly true of Java, too. Since Kotlin can easily call Java, that should mean you can find libraries to do just about anything in Kotlin too. But you can't.

I first ran into this when trying to use a Rest API from Kotlin. Python has an excellent library for this, called Requests. After a bit of googling, I found that someone had ported it to Kotlin, calling it khttp. Then I spent a couple of hours trying to figure out how to get Kotlin to actually use it. That ought not to be hard, but you have to tell the build system where to find a library, i.e. a URL. And none of the documentation, for any library, tells you this. Or sometimes it does, but it's wrong.

I did finally get khttp working, and it was good. But when I returned to my project a few months later it had simply disappeared. It was a single-person project, and the maintainer had got bored with it and moved on to something else. There were bits and pieces about it on the web, and maybe you could get it from here and patch it from there, but it didn't look like a good path.

So I googled around some more, and found another library. It's called Fuel, and it does allow you to make Rest requests. But it is obscure and barely documented. For example, when Rest returns an error, there is no straightforward way to access the details. You can do it in a very clumsy way. But even then, it uses the type system in such an obscure way that there is no way to write a common function that will work across multiple request types (Get, Put, Post and so on). You have to repeat the same ten lines of ugly impenetrable code.

One of the much-vaunted features of Kotlin is coroutine support, allowing you to run lightweight threads that maintain their own stack and state. This looked useful to handle parallel Rest requests, which I needed. Even though it is documented as part of the language, it isn't really. It's part of a library, and has to be explicitly imported. But from where? Everything you can find on the web says you need to "import kotlinx.coroutines". But that doesn't work. Eventually I did figure it out, but I never did convince the IDE. That showed an error right up until I decided I didn't need coroutines anyway.

Another example: a CLI needs the equivalent of GNU readline, so commands can be recalled and edited. The good news is that someone has ported the functionality to Java, in a library called JLine. In fact, they've done it three times - there is JLine, JLine2, and JLine3. They're all different in undocumented ways. But anyway there's hardly any documentation. To find out how to show history (equivalent of the shell 'history' command) I ended up reading the code.

The experience with other libraries has been the same:
  • the documentation is between non-existent and very poor
  • figuring out where to get the library from is near impossible
  • even though there is probably a library for what you want, finding it is a challenge

The Build System

When you start writing Kotlin, you work entirely in the IDE and you don't even have to think about the build system. When you want to run or debug your program, you click on the menu, it takes a second or two to build, and it runs. Life is good.

But if you're writing a program it's probably because you want it to do something. And for that you most likely need to be able to run it without the IDE - from the command line, file explorer or similar. In the Java world, that means creating a .jar file. And that is where the fun begins.

You might reasonably suppose that the IDE would have a button somewhere, "turn this into a Jar file". But it doesn't, nothing like it. So you google it, thinking the menu item you need must just be buried somewhere. But no. What you find is incredibly complicated suggestions about editing files that don't even exist in your environment.

When you do finally manage to persuade something to create a Jar file, and you try to run it, you get a message about not having a manifest for something or other. If you're an experienced Java hand, this may mean something to you. All I know is that the IDE has agreed to build something, but missed out something vital.

Eventually, somehow, I managed to create a menu item that successfully built a runnable Jar file. Problem is, I have no idea how. When I created a trivial "hello world" program just for this exercise, I could never get it to work again. And then somewhere along the way I did something wrong, and the menu item disappeared, never to return.

Ironically, I did once find an article by someone from Jetbrains saying "of course when you write a program, you want to be able to run it without the IDE. Here's what you need to do." The instructions were simple, and they worked. The trouble is, no matter what search I do, I have never managed to find the article again.

Java programs were originally built using something called Ant. That was too complicated, so it was overlaid with another tool called Maven. Then that was too complicated too, so it was overlaid with something called Gradle. That came with its own language, but Kotlin invented a variant where the build requirements are described in a Kotlin mini-program.

So far so good, but all of these tools are mind-numbingly complicated and poorly documented for the casual user. Such documentation as you can find, assumes complete familiarity with the world of Java. Just because Gradle sits on top of Maven, doesn't mean you can ignore Maven. You still sometimes have to go and edit Maven files, which use XML. I've always viewed XML as an object language that only computers should deal with, just like Postscript or PDF. But the Java world is in love with it.

This all really starts to matter if you want to build your Kotlin program as part of some larger project - for example, our entire application. That is built with Make, and heaven only knows Make is a nightmare. But it's a familiar nightmare.

The IDE creates a "magic" file called gradlew. It isn't mentioned in any instructions, nor what to do with it. But a friend told me that './gradlew build' will build a stand-alone jar file from the command line - and sometimes it does. Luckily that worked for me "real" program, though when I tried it with a toy hello-world program it didn't.


Kotlin is great language, and a pleasure to use. Sadly, the nightmare build system, and the lack of any help from the IDE in dealing with it, means it is not really ready for prime time as part of a serious application or project.

Monday, 9 November 2020

My Little List of Useful Principles

This first appeared on my web page, but I thought it deserved to be repeated here on my blog. 

The David Stone Principle

“Never ask a question that has an answer you may not like.” Also expressed as “It is easier to obtain forgiveness than permission”. In other words, don’t ask if it is OK to do something, because the chances are there will be someone who will have some reason why you shouldn’t, and having asked the question (and got an answer you don’t like), you have placed yourself under an obligation to do something about the answer. Whereas if you just got on and did it, you could deal with any objections afterwards. This has two advantages. First, you’ve already done what you intended, and it is pretty unlikely that you will be made to undo it. Second, people are less likely to object after the fact anyway.

Harper’s Theory of Socks

Everybody who has ever packed a suitcase knows that no matter how full the suitcase, no matter how difficult it is to close, there is always some crevice where you can squeeze in one more pair of socks. Those familiar with the Principle of Mathematical Induction will immediately see that it follows that you can put an infinite number of pairs of socks in a single suitcase.

If this is obviously fallacious, it is less obvious why. But in any case it is a useful riposte to the executive or marketing person who wants to add just this one tiny extra piece of work to a project.

Law of Ambushes

I heard this one from Tony Lauck, but he claims to have got it from someone else. Think of an old-fashioned Western, with the good guys riding up towards the pass. They know the bad guys are up there somewhere, and they’re looking every step of the way, scanning the hilltops, watching for any movement, peering around twists and turns in the trail. Suddenly there’s a dramatic chord and the bad guys appear from nowhere, guns blazing. Of course the good guys triumph, except the one you already figured was only there to get shot, but the point is, ambushes happen and take you by surprise even though you expect them, even though you’re waiting for them every second. And they always come from where you weren’t expecting and weren’t watching.

The Lauck Principle of Protocol Design

This one is a little technical, but it is so fundamentally important to the small number of people who can benefit from it, that I include it anyway. Communication protocols (such as TCP) work by exchanging information that allows the two, or more, involved parties to influence each others’ operation. When designing a protocol, you have to decide what information to put in the messages. It is tempting to design messages of the form “Please do such and such” or “I just did so and so”. The problem here is that the interpretation of such messages generally ends up depending on the receiver having an internal model of its partner’s state. And it is very, very easy for this internal model to end up being subtly wrong or mis-synchronised (see the Law of Ambushes). The only way to build even moderately complex protocols that work is for the messages to contain only information about the internal state of the protocol machine. For example, not “please send me another message”, but “I have received all messages up to and including number 11, and I have space for one more message”. There are legitimate exceptions to this rule, for example where one protocol machine has to be kept very simple and the other is necessarily very complex, but they are rare and exceptional. As soon as both machines are even moderately complex, this principle must be followed slavishly.

The Lauck Principle of Building Things That Work

If you don’t understand what happens in every last corner case, every last combination of improbable states and improbable events, then it doesn’t work. Period. Yes, you may say, but it is too complex to understand all of these things right now. We will figure them out later as we build it. In this case, you are doomed. Not only does it not work, but it will never work.

The Jac Simensen Principle of Successful Management

Get the right people doing the things they’re good at, and then let them get on with it. It sounds simple, but it is rarely done thoroughly in practice. It's applicable to all levels of management but especially at more senior levels where there’s a lot of diversity in the tasks to be undertaken.

The Principle of Running Successful Meetings

Write the minutes beforehand. If you don’t know what outcome you’re trying to achieve, you stand little chance of getting there.

Harper’s Principle of Multiprocessor Systems

Building multiprocessor systems that scale while correctly synchronising the use of shared resources is very tricky, Whence the principle: with careful design and attention to detail, an n-processor system can be made to perform nearly as well as a single-processor system. (Not nearly n times better, nearly as good in total performance as you were getting from a single processor). You have to be very good – and have the right problem with the right decomposability – to do better than this.

Harper’s Principle of Scaling

As CPU performance increases by a factor of n, user-perceived software performance increases by about the square root of n. (The rest is used up by software bloat, fancier user interface and graphics, etc).

The Delmasso Exclamation Mark Principle

The higher you go in the structure of an organisation, the more exclamation marks are implicitly attached to everything you say or write. So when a junior person says something, people evaluate the statement on its merits. When the VP says it (even in organisations and cultures that aren’t great respecters of hierarchy and status, like software engineering), everyone takes it much more seriously. It means that as you move up the organisation, you have to be increasingly careful about what you say, and especially you have to be increasingly moderate (which doesn’t always come naturally!).

The Dog-House Principle

A dog-house is only big enough for one dog. So if you don’t want to be in the dog-house, make sure somebody else is. I first heard this applied to family situations (specifically to someone’s relationship with his mother-in-law) but it seems more generally applicable.

Mick's Principle of Centrally Managed Economies

There are three reasons why centrally managed economies don’t work. The first is obvious, the second less so, and the third not obvious at all. This principle was formulated by a friend of mine during the dying days of the Soviet Union. Its applicability to centrally-managed economy is obvious, but it should be borne in mind whenever an organization’s success model involves the slightest degree of central planning.

The first problem is that they assume a wise central authority that, given the correct facts, can figure out the right course of action for the next Five Year Plan. It is fairly obvious that such wisdom is unlikely to be found in practice.

The second problem is that even if such a collection of wisdom did exist, it would only succeed if given the correct input. In the case of the Soviet Union, this means the state of production in thousands of factories, mines and so on, as well as the needs in thousands of towns and villages. But all of this input will be distorted at every point.

The lowliest shopfloor supervisor will want to make things look better than they are, while the village mayor will make things look worse so as to get more for his village. And at every step up the chain of management, the information will be distorted to suit someone’s personal or organizational agenda. By the time the Central Planning Committee gets the information about what is supposedly going on, it has been distorted to the point where it is valueless.

The third problem is the least obvious. Suppose that by some miracle an infinitely wise central committee could be found, and that by another miracle it could obtain accurate information. Its carefully formulated Five Year Plan must now be translated into reality through the same organizational chain that amassed the information, down to the same shopfloor supervisor and collective farm manager. At every step the instructions are subject to creative interpretation and being just plain ignored. The Central Tractor Committee, knowing the impossibility of getting parts to make 20,000 tractors, adds an “in principle” to the plan. The farm manager, knowing that his people will never get enough food supplies to live well through the winter, grows an extra hundred tons of corn and stocks it. And so on.


Tony Lauck led the Distributed Systems Architecture group at DEC, and was my manager for several years. As a manager he was pretty challenging at times, but as a mentor he was extraordinary. He had (still has, I guess) the most incredible grasp of what you have to do to get complicated systems to work, or perhaps more accurately what you have to avoid doing. At first encounter, spending a whole day arguing over some fraction of the design of a protocol seemed like pedantry in the extreme. It was only later that you came to realise that this is the only way to build complex systems that work, and work under all conditions. With the dissolution of DEC, the “Lauck School of Protocol Design” has become distributed throughout the industry, to the great benefit of all. A whole book could be written about it, citing examples both positive and negative – were it not for the fact that Tony is still very much alive, BGP for example would have him spinning in his grave.

Jac Simensen was my boss (or thereabouts) at DEC for several years. It would be an exaggeration to say he taught me everything I know about management, but he was the first senior manager I saw in action from close-up, and one of the very best managers I’ve ever worked for. He certainly gave me an excellent grounding when I quite unexpectedly found myself managing a group of nearly 100 people, by a long way the biggest group I’d ever led at the time.