How Can Software be so Hard? [Feb 09, 2016]




How can it be possible for teenagers to write smartphone apps that make them multi-millionaires when many commercial and Government IT projects fail, despite employing the skills and resources of international IT companies? What is software and how is it developed? How confident do we need to be that it is sufficiently correct, reliable, usable, safe or secure? What evidence would we need? The main reasons why software projects overrun, get cancelled, or deliver inadequate software will be explored, using examples of project failures and the litigations that often result.

Lecture Date: Tuesday, 9th February 2016 – 6:00pm at The Museum of London, 150 London Wall, London, EC2Y 5HN



Lecture Transcript (WORD FILE)Lecture Slides (PPT)View/add Comments

13 Responses

  1. Ilya


    Having watched this lecture, it’s tempting to ask what you think of the opposite side of the spectrum, in particular the ideas summarized as “Objects have failed”, and in particular the opinions that language constraints and other formal constructs, such as static typing/type inference etc being abandoned and a shift towards “self-correcting”/”self-healing” paradigms where the software attempts to discover and recover from faults on it’s own, as opposed to proving programs formally correct? Although I do appreciate the elegance of deriving the programs by iteratively refining formal specifications I can also see the side of the other camp, which says that with the increased amount of software out there and the numerous ways that components can interact, the former would become highly intractable as we build on legacy systems. In summary, what would you say about the idea of self-correcting paradigms?

    1. Self-correction is excellent, where it can be done dependably, but that is hard to achieve even in relatively simple circumstances. Spell chackers are probably the best-known example of an auto-correction algorithm and they have been around for years, yet we all experience incorrect “corrections” frequently. If self-correction can be done dependably, you might think that the authors of spell-checkers would have managed to write algorithms that learn from their mistakes so that the latest versions are perfect. But, of course, the word that is “correct” in one context is wrong in another, so writing a perfect spell-checker turns into the much larger problem of processing natural languages and understanding the meaning of complex sentences – which is still some way from being solved completely, despite the successes of machine-learning (ML) and the vast corpus of Google Books, websites, and search terms that can be used as training data.

      Dependable alogithms for self-correction need to start with dependable algorithms for error detection, because you need to detect an error before you can correct it. This increases the size and complexity of the software – and inevitably increases the number of errors in the code.

      There are probably some applications where an ML approach would be good enough, but you still have to solve the problem of (firstly) deciding how dependable you need the self-correction to be, in your particular application, and (secondly) how you will produce the evidence that shows that you have achieved this degree of dependability.

  2. Interesting.
    I think I would be one of those devils of the “softwafe engineering” community lectures speak about as I’m the only programmer on the project and I do not have any high education degree.
    That said I do believe that programming quality across development world is very low and I try to do my best to ensure stability and quality of the final project.

    We have started project strangely aiming to do it fairly fast (within ~ 6 months, we are indie game developers) and we finally finished it within ~ 18 months, but I think most of the reasons we had to delay our target release date was that during development we have discovered our potential to develop better/larger project. We have failed to be funded by kickstart (twice) but still our product was prized to be very good (even during beta tests, our players were shocked that game was properly playable and stable).
    I think one of the most important reasons we in the end achieved success is that our project have many subsystems which helps to do internal stability testing and automatic error hunt. I remember it was pointed out as something very important in one of the previous lecures and I completely agree, There is no way, and not humanly possible to find all the possible issues self testing was able to hunt down, some of which, even when pointed out by the system were not obvious to notice. You could look at it and not notice the problem.

    As mentioned in the lecture the more programmers the more point of failure, and communication difficulties which lead to inefficient working hour scalability with growing team, but I think its important to mention that small teams suffer from different issue. It is lack of crosscheck, it is in human nature that developer which made certain part of the code, might feel like it works as intended, just because humans tend to reproduce exactly the same path of thinking when resolving exactly the same problem in their head. I have noticed that sometimes explaining the issue to the other team members (even if they have no idea what programmer is talking about) can help you notice thinking flaws and indeed improve code quality.

    1. You have made some good points. Writing assertions into the program can be ver effective in detecting faults and giving sensible error messages, before the program runs on and crashes somewhere else. It’s a good discipline to include a test wherever you know that something should be true. For example (and trivially) ‘if we arrive here then variable “balance” must be equal to or more than variable “payment”, so

      IF (balance < payment) THEN call error ("in module X, balance is less than payment") END IF ' Some languages have an ASSERT operator that provides a convenient way to write these assertions and get meaningful messages; other languages let you define your own assertions. It's a good discipline that can be used for Hoare preconditions and postconditions. Design reviews and code reviews are also valuable quality controls and very cost-effective. Don't wait until you think you have finished before calling a review - use them often as part of your development assurance. They speed up development and share knowledge.

    2. “Writing assertions into the program can be very effective in detecting faults and giving sensible error messages”
      And it should be, when possible, extended to many areas of development which are data driven. Where data, and sometimes even process is produced by non programmers. In our case we had extensive story event library which uses our custom visual scripting to support branching and logic. All together over 6000 nodes with each being able to contain dozens of internal logical blocks, with fair amount of data communicating between nodes and their internal logic. We had two choices, either build strict editor which would limit design flexibility, or build tools which allows to ensure that content is logically correct. Some of the early manual tests could take days, automatic system requires ~1 second, and unlike human check it does not do mistakes. It might though not consider all possible issues if its logic is not perfect. (And it never is ;p)

  3. I’m copying an email from Andras Bokor here, with his permission.

    Dear Sir/Madam

    If you see fit, please pass these comments to Professor Thomas. I hope they are of some relevance, but I have long retired and I am miles out of my depth.

    Project impossible and unreliable sources.

    There was no mention of the possibility that an initial investigation of the plausibility of a project might indicate that it is impractical to attempt it. In some ignorance of the facts, the computerisation of NHS medical records for all patients in the UK might have been in this category. Reasons which might have indicated this include :

    the time required and the manpower needed to scan, let alone read and understand, all such records,

    lack of manpower qualified and able to extract the important items of information for a data base on such a vast scale,

    the quality of the medical records in terms of completeness, intelligibility and accuracy, not to mention omissions (unintentional or even deliberate) … .

    Are methods used in high hazard industries relevant ?

    I seem to recall Hazan and Hazop methods, referenced from the chemical industry, used many decades ago and utilised later in other high hazard industrial activities.

    They involved identification of all probable and significant hazards and identification of the plant required for protection against them.

    Also, plant operation was assessed against all the relevant operational parameters for an increase or decrease in their values so that risky regions of operation could be avoided. Independent Assessment methods were used where justified by the hazard and risk.

    Consequential damage from any potential incidents was also carefully considered in terms of the items listed above.

    Redundancy, diversity and segregation were basic considerations in terms of the items listed above.

    As indicated by the Professor, there is a need for proper engineering assessments in software, but our leaders do not realise it. Until the entry to the profession is not based on rigorous academic qualifications and suitable level of experience, it cannot even be achieved.

    I find it difficult to believe that a pilot trained to land planes manually in an emergency, without reliance on a computer system, could not tell its designers that in an emergency planes do not always land on all wheels at the same time, do not generate equal pressure in them and remain horizontal laterally.

    Hazan and Hazop would have revealed the contradictions in logic mentioned in several parts of his presentation.

    Yours sincerely

    A. Bokor

    1. Thanks, Andras.

      These are all good points.

      I’ll talk about the computerisation of medical records in the NHS next lecture, on April 5th. It was a classically doomed project that several Professors and I tried to save, but a Government Minister blocked out attempts. It neatly illustrates some widely applicable lessons.

      I plan to discuss safety-critical systems in my eighth lecture, on January 10th next year. Hazop methods are very useful, as you say.

      I’m sure that the Airbus designers knew very well that aircraft sometimes land asymmetrically. I haven’t found an explanation of the resons for the specific design landing logic (and I’m investigating whether it was changed following this accident), but it may be that deploying the spoilers and reverse thrust whilst the plane isn’t firmly on the ground creates some further hazards. If I find out, I’ll post the details here.

  4. Quentin Keeling

    Part of your interesting lecture dealt with the basic and [supposedly] obvious aspects of project management as applied to software & IT development. As a retired project manager who has worked on CNI SCADA systems for over 20 years, I am interested on your views of the PRINCE2 methodology, both when used as intended, and when used as a smokescreen.

    1. It’s a few years since I worked with PRINCE2. As with all project management methods, there can be a danger that the main focus of the project manager becomes conforming to the method rather than managing the project. This is a particular danger if there are consultants involved in the project management, because they tend to be experts in the management methods rather than experts in managing successful projects.

      I feel that it is important to regard all standards as a codification of best practice in general, rather than as a straightjacket that every project must struggle to fit into. I like to see project managers tailoring the standards to the project rather than tailoring the project to the standards, but it has to be done professionally – which means that the reasons for the tailoring should be justified in writing as part of the Quality Plan, and they should be reviewed and agreed by the quality manager or (if your organisation doesn’t have one) at least by another experienced project manager who is willing to put their reputation behind the decisions.

      On a small or medium sized project, that review would typically take no more that an hour and it would be an hour well spent.

  5. The transcript for this lecture is on the Gresham College website. It contains some references to books on software development that I highly recommend.

    One that I have not referenced but perhaps should recommend is Managing the Software Process, by Watts S Humphrey. It is published in the Software Engineering Institute SEI Series in Software Engineering and was reprinted with corrections in 1990.

    If anyone wants recommendations for further reading on any computing topic, please post a question on the relevant lecture page and I’ll do my best to answer it.

Leave a Reply