The article is incorrect. At least since the 1980's, many many businesses and institutions, big and small, have adopted rigid software development methodologie

The article is incorrect. At least since the 1980's, many many businesses and institutions, big and small, have adopted rigid software development methodologies ostensibly for business reasons and to ensure some form of "quality." In the 1980's, it was structured design. In the 1990's, it was object oriented design. Since the early 00's it has been some vaguely defined combination of Agile, "clean code", test driven development or "it is only unit tests -- it is not test driven development", code reviews, open offices and other forms of extreme micromanagement. Since the 1980's there have been numerous high profile projects that adhered to each successive software development methodology and imploded, often with rancorous finger pointing. Business people as well as many software developers are attracted to the will-o-the-wisp that there is a one size fits all magic formula for software development. Software development is extremely varied. Some projects are small. Some are large. Some, like flight avionics or medical radiation control software, require very high levels of quality and reliability. Others do not. "Quality" means different things to different people and in different situations. Some software is like the bridge that you never want to collapse. Some software is like the plastic picnic cups that you use a few times and expect to break easily. It depends on the situation, the goals, the priorities which vary substantially and depend on human judgment. Software developers are varied. What is "readable" code for one won't be readable for another. Perceptions of software designs reflect variations in culture, background, training, personality, and so forth. There is no one size fits all methodology and attempting to impose one is often costly and disastrous.