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

reveille and caelumvox.com are live!

As part of a series of projects I'm putting together in an online portfolio, I created reveille (reveille.caelumvox.com) , a website that shows articles of local websites inserted by an AWS Step Function job whose lambdas scrape the website and load it into a MariaDB instance. Some details: The Step Function Lambdas are written in Python, The backend API is written in the Express Node Framework, The frontend app is written in the Angular Node Framework using bootstrap for frontend styling and placement for desktop and mobile browsing. To keep costs low, the frontend, backend, and database are all hosted on one EC2 instance. The frontend and backend are hosted by the same nginx container with a Let's Encrypt certificate. I also created a home page at caelumvox.com as a starting place for visitors, but it still needs a bit of work. The site is hosted on an AWS Cloudfront distribution. HTTPS only!

The TL;DR guide to git

While in the past I've held a pretty high opinion to using mercurial for version control, the majority of version control these days seems to done in git.  Here were the commands I found most useful to get productive with git right away. # Clone a repository from an origin, i.e. my github MaskingUtils repository git clone git@github.com:caelumvox/masking-utils.git # Add a file after it's been updated to stage it for commit, or add a new file git add filename # Commit the file to local repo git commit # Push the file to the origin so the rest of the team can see it git push # List all locally tracked branches git branch git branch --list # Get a list of all branches from the remote git branch -r # Create branch locally git branch develop # Push the branch to the origin repository to make sure it is tracked there git push --set-upstream origin develop # Pulls latest from all local branches tracked from origin; won't pull non-tracked branches git pull --all # Fetch the branch ...