n No Silver Bullet - Essence and Accidents of Software Engineering, | Fred Brooks explains why writing software is hard, and why machines are not going to do it for us anytime soon. The original article appeared in the proceedings of the Tenth World Software Conference. It was subsequently expanded into the, now famous, book, The Mythical Man Month. Brooks believed solving real world problems involves understanding the essential complexity of life. ‘Accidental Complexity’ — the simple type — is the time-consuming part of writing software, for example, listing all 220 countries of the world in a website, or making sure all the buttons in an interface line up correctly. These tasks are tedious — you have to look up all the countries in Wikipedia and make decisions, such as whether the United Kingdom will be denoted ‘UK’ or ‘GB. They don’t need any real ingenuity. ‘Essential Complexity’ is altogether different. It involves understanding the world and setting out the rules in meticulous detail. Brooks argued essential complexity is not susceptible to being sped up by machine processes. Navigating these architectural decisions cannot be automated. He gives us an analogy by comparing writing software to building a house. When you build a house, an architect designs it, an engineer makes the calculations to ensure it is safe, and a construction firm builds it. The construction process dominates the cost and time. In software projects, an engineer writes a program that precisely defines the design and the construction and calculation is done by a compiler — software that takes the design and makes it machine-readable. Compilers operate in a fraction of a second. Making software is, therefore, dominated by the design time, and design is all about capturing the essential complexity of a task. This chapter will try to show where essential complexity comes from, why computers can't tackle this sort of complexity and, therefore, why they can’t write software. Good news for p