Some lessons on software development were learned a long time ago, but have not really sunk in everywhere. Fred Brooks was a project manager on IBM's project t

Some lessons on software development were learned a long time ago, but have not really sunk in everywhere. Fred Brooks was a project manager on IBM's project to launch the System/360 from 1961 to 1964. He took on the responsibility to do the operating system software for the System/360 - OS/360. There were problems during the project of writing the OS software and lessons learned. Ultimately the System/360 (and OS/360) launch was successful, and the product sold well. Brooks wrote a book on the experience in 1975 called "The Mythical Man Month". One of the things the book covers is how a software development project can differ from other kinds of projects, so business should have different expectations. One lesson is if a project is running late, adding additional programmers to the project tends to make the project even later. Another is the second-system effect - that a follow-up to a successful project can be an attempt to reinvent the wheel, which is too complex and with too many features (just keeping to the operating system example, Windows Vista and Hurd could be seen as two examples of this). Another is to "design one to throw away, you will any how". Inevitably for any good product, the software will be refactored or even rewritten. Some ideas from the book are almost universally accepted. Some are debated, such as whether it is good to have a technical team divided into a leader/architect/"surgeon" and assistants (something Brooks favored) or whether other approaches work. If you read over past comments on this forum, or read other programmers and PM's thoughts, the book is considered to have had a lot of valuable lessons for people over the past half century or so. However, I know for certain that despite it generally being considered a source of a lot of wisdom on software development, many of the lessons are ignored nowadays in companies large and small. One of the main takeaways though is 60 years ago, Brooks realized software development projects worked differently than other kinds of projects. He put his lessons into a digestible form in his book almost 48 years ago. But even half a century later, many businesses large and small blithely ignore a lot of these lessons.