For about a year now I've been working for a company in the FX market. As a newcomer to the financial services industry I had to do some background reading. I enjoyed Emanuel Derman's [1] lucid account of his life as a quant. The rise of algorithmic trading in FX over the last couple of years created a tremendous demand for new and more sophisticated models for all financial markets and products. Cornelius Luca [2] wrote the most comprehensive introduction to FX markets I could find. Though a bit lacking on the theoretical side, it gives a good overview about FX products, trading strategies and market dynamics.

The financial services industry is totally hooked on Java. It's just amazing to me, but Java, the second coming of COBOL, is the ecosystem. Unless you look at financial models, which are still mostly done in C++. Although the amount of daily transactions in the FX market is truly mind-boggling, software practice in the industry is in the same wretched state as everywhere else. This is not necessarily a reflection of the intelligence and dedication of the people involved, but when it comes to software, even in high-stakes environments, people work with tools and in a state of mind similar to the Dark Ages. Amazing.

References:

• [1] My Life as a Quant: Reflections on Physics and Finance by Emmanuel Derman
• [2] Trading in the Global Currency Markets, 3rd Edition by Cornelius Luca

I just finished reading A Madman Dreams of Turing Machines by Janna Levin. What a wonderful book! She writes about the private life, love, desperation and achievements of these two giants of the mind, Turing and Gödel:

The human mind can also be reduced to a machine. This idea drives all the others as he runs on grass, past trees, over bridges, through cattle. States of mind can be replaced by states of the machine. Human thought can be broken down into simple rules, instructions a machine can follow. Thought can be mechanized. The connection isn't perfectly clear, but it is there, the catalyst of a great crystal. It is not just that thought can be mechanized. It is mechanized. The brain is a machine. A biological machine. The idea cools him from head to toe, a wave of understanding washing clean his confusion, his muddled notions, and his breath. Shock feels like this: There is no sky or earth. No time, no meaning. It's a throb—a hard silence, a pulse. It is colorless, tasteless, senseless. A white-hot explosion[…]

At the age of twenty-three and for the rest of his life he embraces, without reservation, a mathematics that exists independently of us—although we, by contrast, do not live independently of it. We are biological machines. Nothing more. We have no souls, no spirit. But we are bound to mathematics and mathematics is flawless. This has to be true.

I've mentioned Susan Blackmore's book The Meme Machine before. She gave a lucid and entertaining talk about memes at Poptech 2005.

Links:

• Susan Blackmore's homepage
• Susan Blackmore's talk about Memes at Poptech 2005

Of the many (pulp fiction) books I read during my teens, none made such a lasting impression on me as The Shockwave Rider by John Brunner. His description of a wired planet and computer worms inspired early experiments at Xerox Parc. Here's a quote from the book:

He sent a retaliatory worm chasing Fluckner's. That should take care of the immediate problem in three to thirty minutes, depending on whether or not he beat the inevitable Monday morning circuit overload. According to recent report, there were so many worms and counterworms loose in the data-net now, the machines had been instructed to give them low priority unless they related to a medical emergency.

Recent developments:

• MOSREF and Mosquito Lisp: Mosquito is a secure remote execution framework available for download via the LGPL that combines high-grade cryptography and a small efficient virtual machine on both ends to ensure that intellectual property is protected. It also presents a dynamic environment on a target host that can be reprogrammed on the fly over a secure communications channel to fit the current situation.

References:

• A Short Course on Computer Viruses by Frederick B. Cohen: First concise theoretical work on viruses and mobile code.
• The Little Black Book of Computer Viruses by Mark Ludwig: First publication of working disassembled virus code.
• The Giant Black Book of Computer Viruses by Mark Ludwig.
• The Worm Programs: Classic analysis of the Morris Worm by Eugene H. Spafford.
• The "Worm" programs - early experience with a distributed computation: Early experiments at Xerox Parc.
• You Got the Power: Howard Rheingold's article about the first attempts to commercialize distributed computation.
• How to 0wn the Internet in Your Spare Time: Impressive analysis of the Code Red I worm.

The seminal Engines of Creation by K. Eric Drexler is finally available online! I can still remember the exhilarating feeling I had when I read the chapter about Thinking Machines.

In a sense, artificial intelligence will be the ultimate tool because it will help us build all possible tools. Advanced AI systems could maneuver people out of existence, or they could help us build a new and better world. Aggressors could use them for conquest, or foresighted defenders could use them to stabilize peace. They could even help us control AI itself. The hand that rocks the AI cradle may well rule the world.

Only cooling problems might limit such machines to slower average speeds. Imagine a conservative design, a millionfold faster than a brain and dissipating a millionfold more heat. The system consists of an assembler-built block of sapphire the size of a coffee mug, honeycombed with circuit-lined cooling channels. A high-pressure water pipe of equal diameter is bolted to its top, forcing cooling water through the channels to a similar drainpipe leaving the bottom. Hefty power cables and bundles of optical-fiber data channels trail from its sides. 

The cables supply fifteen megawatts of electric power. The drainpipe carries the resulting heat away in a three-ton-per-minute flow of boiling-hot water. The optical fiber bundles carry as much data as a million television channels. They bear communications with other AI systems, with engineering simulators, and with assembler systems that build designs for final testing. Every ten seconds, the system gobbles almost two kilowatt-days of electric energy (now worth about a dollar). Every ten seconds, the system completes as much design work as a human engineer working eight hours a day for a year (now worth tens of thousands of dollars). In an hour, it completes the work of centuries. For all its activity, the system works in a silence broken only by the rush of cooling water. 



This addresses the question of the sheer speed of thought, but what of its complexity? AI development seems unlikely to pause at the complexity of a single human mind. As John McCarthy of Stanford's AI lab points out, if we can place the equivalent of one human mind in a metal skull, we can place the equivalent of ten thousand cooperating minds in a building. (And a large modern power plant could supply power enough for each to think at least ten thousand times as fast as a person.) To the idea of fast engineering intelligences, add the idea of fast engineering teams.




So, a very good friend of mine finally joined a consulting company. Seems like the code generation and MDA know-how, which we developed during our last project together, is in demand after all.

In his first project though, he'll have to debug some legacy code. The system seems to break down under load. It's a ticketing system and the world cup will be hosted in Germany this year... You get the idea.

We discussed ways to tackle this project and in the end he borrowed four books from my library:

• Software Exorcism by Reverend Bill Blunden
• The Science of Debugging by Matthew A. Telles and Yuan Hsieh
• Software Testing Techniques by Boris Beizer (out of print)
• Software System Testing and Quality Assurance by Boris Beizer (out of print)

When you start a new project or a new job, it helps to have a set of tools available that you can depend on. For me the most important tool is the notebook I keep about ongoing projects. This is where I write down new ideas, stuff I tried, approaches that failed, and successful solutions.

Keeping a laboratory notebook is standard procedure in every lab where stuff is invented and eventually has to be patented. To chemists, biochemists and phycicists the lab notebook is the most precious document in their labs, because it documents their procedures. It allows you to backtrack and to repeat a procedure. It catches and documents your errors.

As Howard M. Kanare writes in his book Writing the Laboratory Notebook:

Few, if any, working scientists writes notes as carefully and completely as they should. Often a seemingly unimportant detail turns out to be crucial. Much experimental work could be better understood, and much repetition of work avoided, if only researchers were more attentive in their notekeeping. The effectiveness of a working scientist can be increased by considering the important role that a notebook can play in experimental planning, observation, and analysis of data. [...] Finally, but perhaps most important, students who are beginning scientific research must be taught how to create a proper record of their work.

I've been a programmer for 25 years. Over the years I've seen many software projects fail and many times it wasn't an issue of failed technology or failed project management or crunch time stress, it was the result of poor leadership.

At the same time all successful software projects had one thing in common: a brilliant technical leader. Here's a quote from Warfighting:

Consequently, trust is an essential trait among leaders –trust by seniors in the abilities of their subordinates and by juniors in the competence and support of their seniors. Trust must be earned, and actions which undermine trust must meet with strict censure. Trust is a product of confidence and familiarity. Confidence among comrades results from demonstrated professional skill. Familiarity results from shared experience and a common professional philosophy.

How do you learn to be a technical leader? The same way you learn how to program: by watching the wizards to their magic and by reading the fine manual (RTFM).

Gerald M. Weinberg, the author of the seminal The Psychology of Computer Programming, wrote such a manual. Becoming a Technical Leader is a remarkably practical and profound book. Weinberg writes:

When we compared successful and unsuccessful systems, we quickly realized that almost all of the successes hinged on the performance of a small number of outstanding technical workers. Some of them were consistent sources of innovative technical ideas, some were interpreters of other people's ideas. Some were inventors, some were negotiators, some were teachers, some were team leaders. What distinguished them from their less successful colleagues was a rare combination of technical expertise and leadership skills. Today, we would say that they were high in innovation, but with sufficient motivational and organizational skills to use in making ideas effective.

These leaders were not the pure technicians produced by the engineering and science schools, nor were they the conventional leaders trained in the schools of management. They were a different breed, a hybrid. What they shared was a concern for the quality of ideas. [...] We called them technical leaders.

Recommended reading list:

• The Soul of a New Machine by Tracy Kidder
• Peopleware by Tom Demarco and Timothy Lister
• Warfighting by U.S. Marine Corps Staff
• Software Craftsmanship by Pete McBreen