This is a foundation read if you want to get into software development. It's an early telling (1975!) of how modern software development got its roots at a time when there simply could never be enough people to deal with the massive crunch of need. Software was, in the 1960's, already beginning to take over everything and no one knew how to produce it.
This book describes several very important concepts. The first, which should be tattooed on the forearm of everyone that ever becomes involved in a software project, is that 50% of the work is testing. And another 33% of the work is what we now call business process analysis and project management. If you're saying, "So only 17% is writing software? That's only 1/6th!" you understand why you need to pick up a copy of this book.
The author speaks about things we still haven't got right. He talks about the need to have a team like a surgery, where there's a principle coder writing the end product, a tools guy prepping the delivery, and others around in other necessary positions. If you think of what we now call DevOps, with people managing the version control tools and the continuous delivery tools, and all the other bits and pieces, you'll see that these ideas were already in our field well before most of us were born.
Still not convinced? You know the old gem that adding more developers to a software project will only make it later? That's from this 1975 book. The author uses a clever analogy: how many babies can be born by adding more women to the tasks of a pregnancy.
Read this book if you're in the software racket. Because our field still hasn't learned these lessons. Yes, it's insanely dated in some respects - the author seems to make a point that developers are male but at this point I've worked with a second-generation female developer. Yes, a lot of the tedium described about updating manuals sounds irrelevant but think instead of updating wikis and SharePoint sites and commenting code instead.