Many fundamental ideas in theoretical computer science will still be true and important in 100 years. The halting problem will still be undecidable and appending to the end of a linked list will still have O(n) complexity. Finding similar fundamental ideas about software engineering is much harder. We will still have some development methodology, but it will likely differ from Waterfall or Agile. We will likely have some modelling tools, but they will likely not be based on UML, DDD or event sourcing. Are there any fundamental ideas about software engineering, or do we just keep re-inventing the wheel?

I believe that fundamental principles of software engineering are of a very different kind than fundamental principles in theoretical computer science. Rather than alluding to mathematics, we need to critically reflect on the history. In this talk, we will look at past development methodologies, debates in the field and important milestones such as the 1968 NATO Conference on Software Engineering. I hope to convince you that critical reflection on those is a fundamental kind of knowledge about software engineering that will make you a better software engineer or craftsman and that will also be as relevant in 100 years as it is today.

"If trials of three or four simple cases have been made, and are found to agree with the results given by the engine, it is scarcely possible that there can be any error." (On the mathematical powers of the calculating engine, Charles Babbage, 1837)If Charles Babbage was right, you would just try to run your program on a few sample inputs and be sure that it will work correctly. Sadly, the world is not so simple. Since the invention of computers, we mostly eliminated hardware issues, but software errors remain. And programmers spent over 60 years finding different strategies for dealing with coding errors.Are software errors a curse that must be eliminated at all costs as advocates of strong typing claim? Are they a professional embarrassment that can be avoided through proper engineering? Should we see errors as an unavoidable part of any modern system and "let it crash" if an unhandled error occurs? Or could we even see errors as a source of creative inspiration?In this talk, I look at a number of strategies for dealing with errors that appeared throughout the history of programming. Understanding the origins of different approaches to errors is not just a fun historical exploration, but it sheds light on current issues in programming, including computer science education, hiring process and the never-ending programming language wars.