I knocked over this long standing member of my reading list this week, a staple of the programming, if not entire comp sci. industries reading list, and I can see why.

If you were putting off reading this like I was, I suggest diving in. It is much more relevant that you would think that a book written in the 70's about coding in the 60's, as the author put it, would actually be.

I also recommend getting the anniversary edition, published 1995, as it has a great retrospective on the entire 1975 edition, including many of the predictions in the No Silver Bullet essay, and the author has responded to many criticisms on statements he made in his 1975 edition.

While this is sure to just be another in a long serious of posts on this book over the last 40 years, I will only go into two points. What stuck with me, and of course, my 2 cents on the No Silver Bullet theory.

The statement that moving a program, from a 'garage app' program, to a commercial program woulds increase dev time by a factor of three struck home with me. Along with the sister theory that an app, to a app that integrates into a systems also requires are factor of three in effort. This culminated in the sum of the two theories that a consumer facing system integrating app equates to an increase of a factor of 9, and related to my experience with writing my very simple console app for slack.

A dirty app to raise an REST message via a console would be maybe 2 hours, (less if you have raised the scaffolding a few times before). Integrating that into both Jenkins, by reading the /api/json responses (append /api/json or /api/xml into any URL, very impressive.), and integrating into Visual SVN by reading the Env. Vars in the hselle that calls my console app and passing them into SVN look to full out the JSON responses did propel development time quite easily towards the 6 hour mark.

After all the pieces were getting along, my desire to look into best practice for console apps pointed me towards the Apache Commons CLI and the .Net CLI Implementation.

Then into Costura/Fody, and packaging it into a single exe.

After that, there was fair bit of refactoring, which I admit is due to my wanting to move it from a one trick pony console app, to something I wouldn't be ashamed of should my colleagues wish to dig around under the hood and extend it. As a result, should I have planned to it to be extensible initially, the refactor wouldn't have been required.

Though, back to the factor of 9 rule, I soon realised I had spend closer to 2 working days on this little console app, and it is still geared towards internal use in our team, than something I would want to distribute with the intention to maintain, my motivation was towards best practices, and a chance to do delve considerably deeper than I typically did with my console apps.

There have been a number of internal software projects I have come across, and internal staff often bring up that we could package it and turn it into a revenue stream. I think is some cases a factor of 3 to put that internal app you use in house, to something you would comfortable putting on the app or play store under you name is pretty conservative.

As for my thoughts on No Silver Bullet, the idea that there would be no single development in a 10 year period would increase productivity by an order of magnitude (factor of 10), is something I agree with. That being said, I believe that development package management, such as nuget, npm, bowser may warrant a brief mention, though more likely a foot note should there ever be a 2015 anniversary edition.

Package management alone does not met the silver bullet criteria of course, in that its only a slight automation over the previous common practice of having your personal repository of packages, or adding the most recent repository into your own projects. Also developers in the 60's if not 40's knew all to well, if not more that their modern counterparts, to not try and re-invent the wheel. I see the change has been in the overall accessibility of packages in general, along with one click integration, which is already taken for granted in how easily we can increase our output by standing on the shoulders of giants, and turn a empty project file into a highly extended framework and customised stack in literal seconds.

I am sure when I revisit The Mythical Man Month later in my career, when its pushing past its 1/2 century since iniltial publishing, there will still be much more than not, which still holds true.