Combating Software System Complexity: Entities Should Not Be Multiplied Unnecessarily

We are often faced with the problem of how to evaluate the quality of a large software system. The primary evaluation metric is definitely functionality and whether the software meets the main requirements (do right things). If there are multiple technical paths to achieve the same functionality, people tend to choose the more simple approach. Occam's Razor guideline "Entities should not be multiplied unnecessarily" sums up very well the preference for simplicity, which is to counter the challenge of complexity. The underlying logic of this preference is: "simplicity does things right. In the 1960s, the Software Crisis (Software crisis -- Wikipedia) was once called because software development could not keep up with the development of hardware and the growth in complexity of real problems and could not be delivered in the planned time. Fred Brooks, a Turing Award winner who led the development of System/360 and OS/360 at IBM, described the plight of a giant beast dying in a tar pit in the bible of software engineering, "The Mythical Man-Month", to draw an analogy with software developers who are mired in software complexity and cannot get out. He also introduced the famous Brooks' Law, "Adding people to a project that is behind schedule only makes it more behind schedule". In his paper "No Silver Bullet -- Essence and Accidents of Software Engineering," he further divides the difficulties of software development into essential and episodic and identifies several major causes of essential difficulties: complexity, invisibility, conformity, and changeability, with complexity leading the way. In 2006, a paper entitled "Out of the Tar Pit" echoed Brooks. This paper argues that complexity is the only major difficulty preventing successful large-scale software development, and that several of the other causes Brooks suggests are secondary disasters resulting from unmanageable complexity, with complexity being the root cause. This paper, too, cites several Turing Award winners for their excellent discussions of complexity. "…we have to keep it crisp, disentangled, and simple if we refuse to be crushed by the complexities of our own making…" "The general problem with ambitious systems is complexity.", "…it is important to emphasize the value of simplicity and elegance, for complexity has a way of compounding difficulties" "there is a desperate need for a powerful methodology to help us think about programs.