Skip to main content

Mythical Man Month - Recap

Even after almost 35 years in print, and with such sweeping changes in the software industry, I still find the lessons and observations in this book relevant in today's development environment. The Man-Month is truly mythical; software projects work best with a very few, sharp developers. When a project becomes late, throwing more people at it makes it later, and communication/synchronization between parties is key. Touching on such topics as unit testing, regression testing, project hierarchies, and niche languages, MM-M predicted long in advance very common, important practices found in today's projects. Brooks even touches on his excitement of object-oriented programming, his skepticism of the benefits of artificial intelligence, and the potential benefits of shrink-wrapped software. Even though they were presented in 1975, these are all correct assertions in 2009.

Being the 20th anniversary edition, Brooks adds new chapters to reflect on the thoughts of the first edition. One new chapter provides an outline of the first edition and annotates in brackets which statements may have changed over the years. As expected, not much has changed; he elaborates on email and web pages as acceptable mediums used to keep developers in sync, and that still, no silver bullet exists that promises order-of-magnitude improvement in software development.

Best lines of the book include:

"Good cooking takes time. If you are made to wait, it is to serve you better, and to please you."

"Adding manpower to a late software project makes it later."

"How does a project get to be a year late?... One day at a time."

"There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity."

Comments

Popular posts from this blog

Software Design Principles - SOLID

The SOLID software design principles weren't called SOLID while I was in grad school, but the concepts were there in my Object Oriented Design course. They're worth mentioning here, primarily because I think once you start coding and become dangerous, it's one of the best ways to stay organized once you incorporate it into your daily coding routines, and it even changes your way of thinking for the better: https://en.wikipedia.org/wiki/SOLID

Best Documentation of a Free Software Package

One oft overlooked artifact in software development is the documentation. An API that is not well documented is no API at all when time is of the essence. That's why I think it is important to discuss some of the tools I have used and their documentation. AutoIt - I love how you simply press F1 within the AutoIt editor and boom, the reference to the particular syntax or function pops up in the help window. This help file is well written, self-contained, and chock full of examples that can be opened up in the editor right from the help, a fantastic symbiotic relationship. After installing AutoIt and giving it a try using their examples, I was able to create client/server scripts, GUI scripts, and window management scripts in no time. Overall, AutoIt is tops in this competition. A+ MySQL - At the bottom of each page of documentation that discusses a particular statement, users are able to post comments containing code snippets for that particular statement. This is great..

Fun with MySQL + PHP

Lately, I've been getting a lot of requests to build websites driven by lots of data, so I've been reading heavily into MySQL and PHP. I've been relying "Beginning PHP and MySQL: From Novice to Professional, Third Edition" by W. Jason Gilmore. I was concerned with his use of connecting to MySQL with a plaintext user name and password, so I went through a few tutorials online: [hvassing.com] [studiolounge.net] and the SQL reference manual: [dev.mysql.com] Of course, they did the same thing. I'm working on trying to implement an SSL solution to login, but unfortunately I think it'll require an X.509 certificate.