
The Sins of IT Projects and why they can fail.
The 2008 Lovelace Medal was awarded to Dr Tony Storey, IBM Fellow and Distinguished Engineer. Maurice Perks, IBM Fellow presented the Lecture on his behalf. In this lecture IBM Fellow Maurice Perks related some of the technical IT experiences that he has encountered during forty years of dealing with complex IT projects within large enterprises that cover finance, manufacturing and government industry sectors. He focused on why IT projects, especially large ones, can have a high risk of failure due to a number of technical factors and how there are recurring themes. He explained how we can often de-risk large IT projects when we understand these factors now that our own industry has matured. To do this we have to understand how the continuing technology developments of our fast-moving industry can be harnessed within the bounds of acceptable risks and probabilities of success. He discussed such challenges as the continuous changes that IT projects face from several quarters, the never-ending search for perfect application code that does not need testing, and some heroic attempts to produce home produced middleware that can turn a traditional commercial enterprise into a budding IT software house. The lecture will not have all the answers but will pose a few key questions that can be asked at the right project moments.


The Sins of IT Projects and why they can fail.
The 2008 Lovelace Medal was awarded to Dr Tony Storey, IBM Fellow and Distinguished Engineer. Maurice Perks, IBM Fellow presented the Lecture on his behalf. In this lecture IBM Fellow Maurice Perks related some of the technical IT experiences that he has encountered during forty years of dealing with complex IT projects within large enterprises that cover finance, manufacturing and government industry sectors. He focused on why IT projects, especially large ones, can have a high risk of failure due to a number of technical factors and how there are recurring themes. He explained how we can often de-risk large IT projects when we understand these factors now that our own industry has matured. To do this we have to understand how the continuing technology developments of our fast-moving industry can be harnessed within the bounds of acceptable risks and probabilities of success. He discussed such challenges as the continuous changes that IT projects face from several quarters, the never-ending search for perfect application code that does not need testing, and some heroic attempts to produce home produced middleware that can turn a traditional commercial enterprise into a budding IT software house. The lecture will not have all the answers but will pose a few key questions that can be asked at the right project moments.
Byron Cook - Proving that Programs eventually do something good.
Software failures can be sorted into two groups: those that cause the software to crash, and those that result in the software hanging. Although crashes are frustrating, we at least know that we must take drastic action (e.g. rebooting). Hangs are psychologically more difficult, as there is always the lingering possibility that we are simply too impatient and should wait a while longer for the machine to respond.
BCS Needham Lecture 2009
Byron Cook - Proving that Programs eventually do something good.
Software failures can be sorted into two groups: Those that cause the software to crash, and those that result in the software hanging. Although crashes are frustrating, we at lease know we must take drastic action (e.g. rebooting).
Hangs are psychologically more difficult, as there is always the lingering possibility that we are simply too impatient and should wait a while longer for the machineto respond.
Software failures can be sorted into two groups: Those that cause the software to crash, and those that result in the software hanging. Although crashes are frustrating, we at lease know we must take drastic action (e.g. rebooting). Hangs are psychologically more difficult, as there is always the lingering possibility that we are simply too impatient and should wait a while longer for the machineto respond.
Software failures can be sorted into two groups: Those that cause the software to crash, and those that result in the software hanging. Although crashes are frustrating, we at lease know we must take drastic action (e.g. rebooting). Hangs are psychologically more difficult, as there is always the lingering possibility that we are simply too impatient and should wait a while longer for the machineto respond.
Software failures can be sorted into two groups: Those that cause the software to crash, and those that result in the software hanging. Although crashes are frustrating, we at lease know we

Software failures can be sorted into two groups: Those that cause the software to crash, and those that result in the software hanging. Although crashes are frustrating, we at lease know we must take drastic action (e.g. rebooting). Hangs are psychologically more difficult, as there is always the lingering possibility that we are simply too impatient and should wait a while longer for the machineto respond.
Software failures can be sorted into two groups: Those that cause the software to crash, and those that result in the software hanging. Although crashes are frustrating, we at lease know we must take drastic action (e.g. rebooting). Hangs are psychologically more difficult, as there is always the lingering possibility that we are simply too impatient and should wait a while longer for the machineto respond.
Software failures can be sorted into two groups: Those that cause the software to crash, and those that result in the software hanging. Although crashes are frustrating, we at lease know we must take drastic action (e.g. rebooting). Hangs are psychologically more difficult, as there is always the lingering possibility that we are simply too impatient and should wait a while longer for the machineto respond.
Software failures can be sorted into two groups: Those that cause the software to crash, and those that result in the software hanging. Although crashes are frustrating, we at lease know we


What will a companionable computational agent be like?
Professor Yorick Wilks, Oxford Internet Institute at Balliol College.
The lecture begins by looking at the state of the art in modeling realistic conversation with computers over the last 40 years. I then move on to ask what we would want in a long-term conversational agent that was designed for a long-term relationship with a user, rather than the carrying out of a single brief task, like buying a railway ticket. Such an agent I shall call "companionable": I shall distinguish several functions for such agents, but the feature they share will be that, in some definable sense, a computer Companion knows a great deal about its owner and can use that information.
By way of illustration, the lecture describes the functionality and system modules of a Senior Companion (SC), one of two initial prototypes built in the first two years of the EC Companions project. The SC provides a multimodal interface for eliciting and retrieving personal information from the elderly user through a conversation about their photographs. The Companion, through conversation, elicits life memories, often prompted by discussion of their photographs. The demonstration is primitive but plausible and one of its key features is an ability to break out of the standard AI constraint on very limit pre-programmed knowledge worlds into a wider, unbounded world of knowledge in the Internet by capturing web knowledge in real time, again by Information Extraction methods. The lecture finally discusses the prospects for machine learning in the conversational modeling field and progress to date on incorporating notions of emotion into AI systems.

Dr Joël Ouaknine - Timing is Everything
Our society is becoming increasingly reliant on computer systems; think of mobile phones, Sat Nav, the Internet, and so on. A modern car typically harbours tens to hundreds of microprocessors, themselves running several tens of million lines of code, controlling such critical components as fuel injection, airbags, and anti-lock braking systems. Many of these devices operate in the background, reacting in real-time to a complex environment, and subject to a wide array of functional and timing constraints.
A major modern scientific challenge is to devise effective methodologies for accurately modelling and analysing such real-time computer systems, in order to verify and guarantee that they function as they are intended to.
In this talk, I described some of the fundamental paradigms and algorithms for reasoning about real-time systems. Perhaps surprisingly, several basic questions of decidability and complexity turn out to be remarkably difficult, and a number of problems remain open after some two decades of work in the field. I presented, at a high level, some of the deep connections that are found between real-time verification and mathematical logic, automata theory, combinatorics, and graph theory.
Finally, I discussed how we expect to translate parts of the rich body of theoretical work in real-time systems into concrete engineering achievements, in the context of ongoing collaborations with industrial partners from the automotive and avionics sectors.

