The Mythical Man-month

Frederick Phillips Brooks

Mentioned 13

No book on software project management has been as influential and timeless as The Mythical Man-Month. Blending software engineering facts with thought-provoking personal opinions, author Fred Brooks offers insight into managing the development of complex computer systems. In this twentieth anniversary edition, the original text is accompanied by Fred Brooks' current advice and thoughts based on the newest developments in the computer industry. In four added chapters, including his 1986 article, No Silver Bullet, Brooks asks whether there is yet a silver bullet for software productivity and gives his latest opinions on the mythical man-month.

More on

Mentioned in questions and answers.

This is a poll asking the Stackoverflow community what non-programming books they would recommend to fellow programmers.

Please read the following before posting:

  • Please post only ONE BOOK PER ANSWER.

  • Please search for your recommendation on this page before posting (there are over NINE PAGES so it is advisable to check them all). Many books have already been suggested and we want to avoid duplicates. If you find your recommendation is already present, vote it up or add some commentary.

  • Please elaborate on why you think a given book is worth reading from a programmer's perspective.

Note: this article is similar and contains other useful suggestions.

How to Win Friends and Influence People

by Dale Carnegie

How to Win Friends and Influence People

Although this was first published in 1936, the advice contained within is still as fresh and appropriate as ever. Don't be put off by the name. This isn't some underhand guide to having your way with unsuspecting victims, but rather common sense advice on how to get on with people, how to nurture relationships and make the most of yourself and your fellow man (and woman).

It is well known that technical folk (including programmers) are often thought of as not being terribly 'people oriented' (whether this is a justified stereotype or not is subject of another discussion) and so this book is an invaluable resource for teaching you the finer points of human interaction.

It's warm, heartfelt, sturdy, straightforward and timelessly written. Highly recommended.

The Goal: A Process of Ongoing Improvement

by Eliyahu M. Goldratt and Jeff Cox

To elaborate: It is a book on how to approach problems. To identify bottlenecks in your system and work on them. So in short, it isn't a programming book, but shows (in novel format) how to problem solve -- and is thus very valuable to a programmer.

[Update Gishu] It's an eyeopener on how the throughput of your entire system depends on the bottlenecks. Optimizing other stages/operations will not produce any results. Although this is ingrained in developers who have had experience optimizing a scenario in their app; however zooming out to a more higher level and applying this can have profound gains. Beck's XP Book has a dedicated chapter on the Theory Of Constraints. Programmers who move onto Leads/PMs will find this a valuable addition to their toolkit.

Surely You're Joking, Mr. Feynman!

alt text

This book will inspire anyone to think and be original.

This might not be a popular one, but

Gravity's Rainbow

by Thomas Pynchon

Gravity's Rainbow

Gravity's Rainbow is my favorite book of all time. I read through the whole thing last summer, and I'm in the process of reading it again. From a writer's point of view, it's pure, beautiful art. However, I recommend it here because it really forces the reader to think and make a lot of mental connections.

Of course, this book has a reputation for being impossible to finish. It's definitely the hardest book I've ever read. Pick it up at your own risk.

Don't Make Me Think by Steve Krug. An essential book about web usability. As Krug says, "Common sense isn't always obvious."

alt text

(Hint: has good usability)

Update: This is now part of the library at work. I've gotten about five people to read it so far. 100% positive reviews, predictably.

Here's a strange one for you all to think about.

On The Road by Jack Kerouac.

It's a modern classic that everybody should read, and I'd be very surprised if English or Media Studies students weren't recommended to read it at some time. Reading should not only be informative and educational, but enjoyable as well. If you're not going to read a book for pure fun now and again then you'll only end up frustrated with the books you need to read as a programmer/developer.

This book is a real eye-opener; a book that'll really make you think about your own life, and for a programmer whom spends their day dealing with pure thought-stuff it's a great way to get you thinking on a different track.

I would heartily recommend Jennifer Government to any software developer. Amazon Wikipedia

It's a very fast paced action story that's excellent to clear your head with. It's a fun book to read (will make you laugh), and the characters are rather tragic (will make you feel more satisfied at work). This is one of those books that is hard to explain the content without fear that people will think you different and odd, but all the same you must tell everyone about (I.e. makes you talk to people).

The Humane Interface by Jef Raskin.

You can see some of the effects of these ideas in Aza Raskin's (Jef's son) Enso project and the Ubiquity Firefox add-on.

Kicking the Sacred Cow

Questioning the Unquestionable and Thinking the Impermissible

by James P. Hogan

alt Kicking the Sacred Cow

Masters of Doom !!

God programmer meet God marketing guy, and no it's not Steve Woz and Steve Jobs, but it's the Johns, Carmack and Romero.

Business, gaming and programming all rolled into one. a definitely page turner all the way until the end.

The Mythical Man-Month

by Fred Brooks

The Mythical Man Month

My personal opinion is, apart from programming, in life we need to find a balance, about everything (or keep striving for it). Many times, I have found myself getting too immersed in one aspect of life (frequently programming/work) at the cost of others. Over the years I have learnt to recognize this and act accordingly.

In work, sometimes I have come across pretty difficult people, making it hard to work with them (not just my opinion, but also of other team members). Previously I used to try hard to convince them, make them more helpful, etc. and get frustrated when I don't succeed.

But this book Tigana, by Guy Gavriel Kay helped me understand that sometimes a person can be inherently complex, hard to work with, without he/she helping it. It is a science fiction novel, and it may not be completely appropriate here, but it helped me work better with my team, so I am linking to it here. It helped me become more objective in dealing with people I work with.


Jeffrey K. Liker - The Toyota Way (Amazon link). A good if at times semi-boring read, but loads of information from the company which invented Lean.

Games People Play by Eric Berne.

alt text

IMHO it is a very useful aid to understand and deal with office politics (among others).

We think we’re relating to other people – but actually we’re all playing games.

Forty years ago, Games People Play revolutionized our understanding of what really goes on during our most basic social interactions. More than five million copies later, Dr. Eric Berne’s classic is as astonishing–and revealing–as it was on the day it was first published. This anniversary edition features a new introduction by Dr. James R. Allen, president of the International Transactional Analysis Association, and Kurt Vonnegut’s brilliant Life magazine review from 1965. We play games all the time–sexual games, marital games, power games with our bosses, and competitive games with our friends. Detailing status contests like “Martini” (I know a better way), to lethal couples combat like “If It Weren’t For You” and “Uproar,” to flirtation favorites like “The Stocking Game” and “Let’s You and Him Fight,” Dr. Berne exposes the secret ploys and unconscious maneuvers that rule our intimate lives. Explosive when it first appeared, Games People Play is now widely recognized as the most original and influential popular psychology book of our time. It’s as powerful and eye-opening as ever.

alt text

As well as the mentioned Gadwell's Tipping Point, Blink is a good choice.

A Brief History of Everything by Ken Wilber.

Front cover

In the ambitiously titled A Brief History of Everything, Wilber continues his search for the primary patterns that manifest in all realms of existence. Like Hegel in the West and Aurobindo in the East, Wilber is a thinker in the grand systematic tradition, an intellectual adventurer concerned with nothing less than the whole course of evolution, life's ultimate trajectory—in a word, everything. . . . Combining spiritual sensitivity with enormous intellectual understanding and a style of elegance and clarity, A Brief History of Everything is a clarion call for seeing the world as a whole, much at odds with the depressing reductionism of trendy Foucault-derivative academic philosophy.

The Fountainhead by Ayn Rand. Atlas Shrugged is already on this list, but the Fountainhead deals more with craftsmanship and integrity, rather than supply-side economic theory. Definitely worth a read for anyone in a creative field.

Could not put this one down, The Evolution of Cooperation by Robert Axelrod. Its a fascinating read and as game theory books go it's pretty accessible.

Snow Crash By Neal Stephenson

alt text

Ender's Game by Orson Scott Card

alt text

The Dirty Dozen

alt text

An analysis of the 12 worst Supreme Court decisions

Great and interesting book about how our liberties are being trodden on by the government. Libertarian viewpoint, but objective.

A Random Walk Down Wall Street

Burton G. Malkiel

Nothing else will teach you better how to get a handle on your money.

Wikipedia article

alt text

Niccolo Machiavelli's The Prince. After wondering why people acted so strangely at work, this book was the first of many, that taught me why.


alt text

How was JPod not posted? It's like a (already posted) Microserfs with internet. It's typical Coupland novel, must read for every techie, geek, webz hipster.

Here are some quotes

"You googled her?" "Of course I did. Didn't you?" I'd somehow forgotten to perform this essential task.

“After a week of intense googling, we’ve started to burn out knowing the answer to everything. God must feel that way all the time. I think people in the year 2020 are going to be nostalgic for the sensation of feeling clueless.”

“It turns out that only twenty percent of human beings have a sense of irony – which means that eighty percent of the world takes everything at face value. I can’t imagine anything worse than that. Okay, maybe I can, but imagine reading the morning newspaper and believing it all to be true on some level.”


Love is the Killer App by Tim Sanders - it's for every professional.

Nothing too programmer-specific, but being in the industry that we are, it helps immensly to have a positive mindset depicted in this book.

alt text

Note: I had to move this book from my previous answer to here, to comply with the question's specific rule that one post -> one answer

This is probably not going to be popular, but "If liberty means anything at all it means the right to tell people what they do not want to hear."

In the Beginning was the Command Line

by Neal Stephenson

It's very dated, but I have yet to find a single book (or essay for that matter) that gives a quasi-outsider's view of an industry that the public is apathetic to understand. The insights and descriptions are spot-on, even though the conditions have dramaticly changed over time.

In the Beginning was the Command Line

The Inmates Are Running the Asylum

by Alan Cooper

alt text

It's about using the right language to talk about projects - using stories (and personas) instead of 'features' to talk about stuff that needs to be realized. Also a lot of emphasis on interaction design and related activities. Delivering what is needed instead of what is asked for.

Beyond Code by Rajesh Setty

alt text

Also read these free manifestos

  1. 25 Ways to Distinguish Yourself
  2. Making the Most of Your Time: Going Beyond To-Do Lists

(Note: moved the other book to a separate answer)

Awaken the Giant Within by Anthony Robbins.

alt text

The Black Swan: The Impact of the Highly Improbable

alt text

This book as about why stock markets are not predictable like casinos and the lottary. It is very readable though querky. It will help you to understand when statistical techneques do not work, why math is not understanding, why project managers can't predict schedules and how they can with less effort.

The book does not go into heavy math but will give you a feal for when the math can and more ofter can not be used.

Author: Nassim Nicholas Taleb. Also wrote 'Fooled By Randomness'

Read it if you work with mathematics, statistics or finance - Or if you have a pension.

Simon Singh's Fermat's Last Enigma is one of the greatest books I have ever read.

This non-programming book has taught me a lot about running after the solution of a problem, no matter how old and complex it is.

alt text

I recommend

The Emperor's New Mind

by Roger Penrose

Somehow in the line of Godel, Escher, Bach but, I think, easier to read.

First Things First - another equal great book from Stephen R. Covey.

alt text

Dealing with people you can't stand:

Dealing with People You Can't Stand: How to Bring Out the Best in People at Their Worst (Paperback) ~ Dr. Rick Brinkman (Author), Dr. Rick Kirschner (Author), Dr. Rick Kirschner (Author), Dr. Rick Brinkman (Author)

Sensation & Perception by E. Bruce Goldstein will really pull a lot of software engineers out of their comfort zones. I found it to be fascinating when I started thinking about effective scientific visualization techniques with the user's physiology and psychology in mind. Issues with the user's potential for color blindness, visual acuity, attention span and information processing abilities are just some of the reasons why I keep going back to this book.

If you're a Python developer, you will not get around viewing Monty Python stuff. But to quickly look up a quote you find in any Python doc, I really recommend those:

alt text

(as well as part two, they're great; Amazon) and

alt text


Reading doesn't give you the great look of a puzzled Michael Palin or the anger of a furious John Cleese, but it still is a worthwhile lecture.


The Soul Of A New Machine

by Tracy Kidder

"The Ultimate History of Video Games" of course!

Why? Because in one book you get history, fun, anecdotes, business decisions, project management, opinions, wonderful quotes, the hardware and the software ... all in all portraying an industry that went through numerous cycles, ups and downs, deaths and reincarnations. But most of all: Steven Kent managed to make this book a very entertaining read, you'll be captivated by each chapter.

alt text


This is similar to another question. Here is a link to my answer over there.

Now, Discover Your Strengths is my favorite personal/career development book. It teaches the most successful people become successful by focusing on building on their strengths, rather than covering up weaknesses. This book helps you find out where your strengths lie.

Waltzing With Bears

by Tom DeMarco and Timothy Lister

Waltzing With Bears

Great background on what managing risk means and lots of good tools for quantifying risks. They discuss a risk estimation tool which uses statistics to produce a pragmatic and reality-based understanding of the effects that risks will have on a given projects completion date and confidence level.

The prologue on "The Ethics of Belief" is not to be missed.

The Effective Executive

Concise, bare essential and time-less!

alt text

The First Quarter : A 25-year History of Video Games. Unabashed old-school video game geekery.

alt text

One hundred years of solitude

by Gabriel Garcia Marquez

Hackers: Heroes of the Computer Revolution

by Steven Levy

Does a great job of outlining some of the eras in computing, from the enviroment that sprung up around the Tech Model Railroad Club at MIT, to the Homebrew Computing in the bay area, to the story of the game companies of the early 80s. Especially the MIT section has wonderful descriptions of hackers at work, doing what they do best (in a wholly non-technical writing style), bumming instructions, making the machine do their bidding, and in the mid-seventies, it describes the self-made community of hardware hackers (including Wozniak), who built their own computers. Hugely entertaining, and a good way to understand where some of these communities originate from (academics, hackers, tinkeres).

Cover for Hackers: Heroes of the Computer Revolution

The Fifth Discipline:.

Several important things: System thinking, System Archetypes, etc.

alt text

alt text

If you don't want your job to be outsourced (as have happened to many programmers) then you need to read this book, A Whole New Mind - Why Right-Brianers Will Rule The Future, actualize it, and put it into practice yesterday!

I would recommend: "Code" by Charles Petzold.

It completely opened my eyes on how computers actually work, explained and illustrated clearly. I learned that computers have no inherent understanding of numbers, letters, words or anything like that. These were human concepts and it was up to the computer programmer (at a very low level) to present they patterns of bits from computer memory to something users would find meaningful.

Despite its title, "Code" has nothing to do with coding, but explains how computers work at the electrical level.

Peopleware: Productive Projects and Teams

by Tom DeMarco and Timothy Lister

alt text

This classic book encourages us to think about the people instead of the process. It's full of practical advice on team building, productivity and office environments. It's a must read, not just for managers, but anyone related to software development.

Get two copies, one for you and one for your manager.

Zen and the Art of Motorcycle Maintenance

by Robert M. Pirsig

alt text

This book is many things, but you could say it's sort of a philosophical take on what it means to "grok" something.

Commentry from Garth Gilmore:

I credit this book with teaching me more about software development than any programming book I ever read.

The central thread in the book is how our romantic (artistic) and classical (technical/rational) perceptions of the world are both derived from how we perceive quality in the environment around us. This understanding is then applied to apparently mundane tasks like motorcycle maintenance.

To give some examples of how this applies to coding:

  • The section on how to approach the motorcycle with a 'quality mindset' that leads to progress is just as applicable to reaching 'the zone' in programming.
  • The section on 'gumption traps' that prevent progress and lead to you damaging the machine is priceless. The solutions that are presented work just as well when trying to modify legacy code without introducing bugs.
  • The section on how a purely classical description of an engine part is useless (because it lacks any place for the user to stand) should be read by anyone involved in requirements analysis.

Long story short its a good read :-)

Simon Singh's The Code Book is a great book about how cryptography was born and how people is always trying to challenge it.

alt text

The Hitchhiker's Guide to the Galaxy

by Douglas Adams

alt text

Life, the universe, and everything

"See first, think later, then test. But always see first. Otherwise you will only see what you were expecting. Most scientists forget that." -- Wonko the Sane

Never Eat Alone: And Other Secrets to Success, One Relationship at a Time

by Keith Ferrazzi


Comments from duplicate answer by Flory:
I did not think that I would like it before I got the book but I really enjoyed it. It is basically about how to build a relationships. Prior to reading it I expected it to be very trite and about how to use people for your own ends. Instead it was the opposite in how to be used to everyone's ends. Very interesting.

What is the name of this book?, by Raymond Smullyan. It is a wonderful book of puzzles about the intricacies of logic.

Hyperspace: A Scientific Odyssey Through Parallel Universes, Time Warps, and the 10th Dimension

by Michio Kaku

alt text

There's a lot of space out there to get lost in.
-- John Robinson, Lost in Space


by Neal Stephenson

Cryptonomicon by Neal Stephenson

This book follows parallel stories of a World War II code breaker and his present day descendant, and deals a lot with the development of computers (Alan Turing is actually a character in the book). A geek's must-read!

Stranger in a strange land because every programmer should grok the word "GROK".

Lessons Learned in Software Testing by Kaner, Bach, and Pettigrew. Brilliant book, easy to read.

The Thermodynamics of Pizza by Harold Morowitz.

This could have all kinds of morals, depending on how you take it. 1. You can use science to improve EVERYTHING! :-) 2. Make sure you choose the right level of abstraction when designing and coding. 3. You can really improve your life if you just take a few minutes to think about it.


Getting Things Done

by David Allen.

alt text

The Moon Is A Harsh Mistress

Amazon - Wikipedia

The Moon Is A Harsh Mistress

Written in 1966 this classic science fiction novel takes place on the penal colony Luna (the moon). The story is told by the only programmer/computer repairman on Luna, Manuel. Manuel has a secret. The master computer (Mike) that controls all of Luna has become a sentient AI and happens to have Manuel as its only friend. Mike is rough around the edges at first, its speech is fuzzy and it plays childish but dangerous jokes with its god-like abilities. As time wears on Mikes abilities fully develop into a mature being. With Manuel's guidance they will go on an adventure together that spurs the revolution of freeing Luna from Earth!

This novel is the first Robert A. Heinlein novels I have read but will certainly not be the last. The fact that this book was written in 1966 still astonishes me! It has barely any dated parts and could easily pass for a contemporary novel. It wont he Hugo award for best novel.

Truly one of the better "programmer" style novels I have read. Great adventure the whole way through. If anyone has a suggestion as to which Heinlein novel I read next, please leave a comment!

Written in 1950, Dianetics: The Evolution of a Science describes the optimum computer as an introduction to a science of the mind.

Nineteen Eighty Four

by George Orwell


The Curious Incident of the Dog in the Night-Time

by Mark Haddon

alt text

It will give you some perspective of your odd co-workers.


This is an amazing book that details some very counter-intuitive conclusions about the LACK of THINKING actually predominates our decision process.

Player Piano by Kurt Vonnegut

Beyond Fear by Bruce Schneier.
Beyond Fear Book

From Amazon: "Schneier provides an interesting view of the notion of security, outlining a simple five-step process that can be applied to deliver effective and sensible security decisions. These steps are addressed in detail throughout the book, and applied to various scenarios to show how simple, yet effective they can be....Overall, this book is an entertaining read, written in layman's terms, with a diverse range of examples and anecdotes that reinforce the notion of security as a process".

Or just consider it a straight read on understanding what security means - whether for computers or in real life. It can give you the tools to handle the ginormous amounts of FUD we encounter every day.... And it's entertaining, besides. (Even got my father to read it, and he's enjoying it...)

Universal Principles of Design, by William Lidwell, Kritina Holden, and Jill Butler

Universal Principles of Design

One of this biggest issues I have with many programs I have used is the lack of design put into the interface and into the product. This book goes in-depth describing how to enhance the usablilty within a interface. It also tells you all of the basic principals and rules of design, and they give many examples for many different applications whether its techinical or non-technical. The book reads a little like a college classroom book (and it probably is for many design schools), so it the not the most exciting thing to read, but I find the most informative when it comes to interface design.

The Tao of Physics by Fritjof Capra

One notable premise contained within this book reminds me of the saying "If you go far enough away, then you're on your way back home". For example, the Eastern and Western approaches to philosophy and science were so diametrically opposed for centuries but perhaps they're coming around the other side towards similar conclusions these days?

It may be 30 or so years old, but it's still very much worth the read.

alt text

My second choice would be to read Neuromancer by William Gibson (or watch The Matrix which is along the same lines I guess).

I can't believe I didn't see this already listed:


by Frank Herbert

Dune Cover

Dune is the pinnacle of Sci-Fi novels!

I've been really enjoying haiku recently. To that end, I'd very strongly recommend The Haiku Handbook: How to Write, Share, and Teach Haiku by William J. Higinson.

Book Cover

I recommend reading/writing haiku as a way to relax.

The Tipping Point is one of the best books that I have ever read.

Eats, Shoots & Leaves: The Zero Tolerance Approach to Punctuation

by Lynne Truss

Becoming a better communicator in people language, I believe, makes you a better communicator in code. Punctuation is a very good place to start improving your writing.

The Game

Every programmer should read this book to learn how to pick up women.

The game

Fortune's Formula

alt text

Information theory, betting, value of information, etc.

Fantastic read.

Flow: The Psychology of Optimal Experience

by Mihaly Csikszentmihalyi

alt text

The best and most productive coding is done in a flow state. This is a psychological study of the phenomemon. Although the book is scientifically rigorous it remains accessible to the lay-person.

21st Century Jet: The Making of the Boeing 777, by Karl Sabbagh

From coffee cup holder to three-hundred-foot wing, this book is the story of how a group of people came to build a brand new aeroplane.

The book describes the development of the Boeing 777, from initial concept, through requirements gathering, design, development, testing, production, and delivery. The engineers and management implemented a new development system, overcame changing requirements, met strict safety requirements, and continually optimized the solution. It describes how the designers and engineers worked to make the aircraft easier, safer, and more intuitive for everyone who would come in contact with it (air crew, maintenence crews, and passengers).

Software developers can learn a lot from this book. It's very well written, it reads like a novel. I've read it twice and highly recommend it.

Boeing Computer Services president John Warner said, the Boeing 777 is "three million parts flying in close formation." Sounds like software to me.

Charles Perrow's "Normal Accidents" investigates what can happen when complex technology goes horribly wrong, and formulates his theory of the "normal accident": complex, tightly coupled systems will have accidents, because minor faults interact with catastrophic consequences. We see this all the time in programming and systems administration, and yet, as far as I know, few of these concepts are understood outside safety engineering.

(He also writes very well, and brings life to what could have been a rather dry book).

alt text

Joel Spolsky's "Best Software Writing I"

Women, Fire, and Dangerous Things

by George Lakoff

alt text

It's a book about how people categorize things, and about reasoning in general. It's long and extremely boring for some people, but it is still great.

If you live on the Unix side of the world, The Art of UNIX Programming by Eric Raymond (see also here). Despite its title, it is not a programming book, and it contains very few lines of code indeed. It's the best book I know about the Unix philosophy.

I found Zero: The Biography of a Dangerous Idea to be pretty decent. He has a followup to this called Decoding the Universe: How the New Science of Information Is Explaining Everything in the Cosmos, from Our Brains to Black Holes which I have but haven't read yet so I can't comment on how it is.

alt text

Secret Rendezvous by Kobo Abe. Abe's the frickin' man, man.

But seriously, if you like Murakami, you owe it to yourself to check out Abe.

Happiness is a Choice by Barry Neil Kaufman

It's a great book that can help you understand you can choose how to feel. Turns out you can be responsible for a lot more of your emotions than you think.

Another one from a different angle from prior posts: Gödel, Escher, Bach: an Eternal Golden Braid, by Douglas Hofstadter.

alt text

The Four Steps to Epiphany

I can not believe this book has never been mentioned!! It is one of the best book about product management I have read in years. If you are working for a startup, it is a must read.

alt text

The Milkshake Moment: Overcoming Stupid Systems, Pointless Policies and Muddled Management to Realize Real Growth by Steven Little

The Milkshake Moment

The Right Stuff by Tom Wolfe


Walter Murch's "In the Blink of an Eye"

Speed Reading, by Robert L. Zorn:

alt text

Or any other Speed Reading text. Learning my own quirks about how I read has helped me to be conscious of other aspects of how I think. Having the ability to control my reading speed has proven to be invaluable. I still choose to read books for pleasure at my previous reading speed with all its flaws.

The Illuminatus! Trilogy by Robert Shea and Robert Anton Wilson. In many ways, this book changed the way I do my thinking. Not sure whether it is good or bad to completely distrust anything and everything, but at least it keeps ones mind critical instead of automatically accepting something as truth without questioning.

The book also introduced me to the concepts of discordianism, which I find having quite a few interesting points.

Outliers: The Story of Success by Malcolm Gladwell

I just bought it on Audible last week and I can't stop listening to it. It goes through the factors of successful people (ex: Bill Gates, Bill Joy, The Beatles). Fascinating!

Enigma: The Battle for the Code

by Hugh Sebag-Montefiore

alt text

Having a bad week at work? Well at least when you can't figure out some algorithm people aren't dying in their hundreds in the freezing North Atlantic waiting on you to work it out.

As well as being a great read about the dawn of the modern computing age, this book can help with perspective.

Dreaming in Code

by Scott Rosenberg (Amazon Wikipedia)

Cover image

A great book about the development process. It also highlights how developers are doomed to keep repeating the same mistakes over and over again

Juggling for the Complete Klutz

Juggling is mandatory. All programmers must juggle. Sorry, it's a rule.

Rick Cook - The Wiz Biz

alt text

This is a compilation of the first two novels in a series, called 'Wizard's Bane' and 'Wizardry Compiled', respectively.

It all began when the wizards of the White League were under attack by their opponents of the Black League and one of their most powerful members cast a spell to bring forth a mighty wizard to aid their cause. What the spell delivers master hacker Walter "Wiz" Zumwalt. With the wizard who cast the spell dead, nobody can figure out what the shanghaied computer nerd is good for--because spells are not like computer programs.

Lots of in jokes for the Unix/Linux crowd to enjoy. Pretty much anybody in the software industry will enjoy it, I think.

As a new developer who is the only software guy on staff I have faced a few challenges but possibly the most difficult has been time estimates. I strugle every time I have to give a project estimate.

My question then is; If I do not have any experience and I don't have a fellow dev in my environment, how do I provide a solid estimate? I have read Joel Spolsky's article on Evidence Based Scheduling but how can that apply if I do not have any evidence?

I appreciate any advice on this subject.

Although it is very rough, I estimate on Lines of Code. This parameter, whose meaning for productivity is close to zero, still gives you an idea of the complexity of a project.

Measure the fact that on average, a developer can write circa 200, max 300 lines of code per day. Keep into account that just for coding of a single man army:

  • A small project of 1000 lines of (logic) code can be done in one or two weeks
  • An average complexity project of 10.000 lines of (logic) code could be completed in two or three months.
  • A large project of 100.000 lines of (logic) code requires at least a couple of years

To the logic code, you have to add the testing, which is already included in the previous estimates. To have a clue of the complexity, the Gimp is 600.000 lines of code, a kernel ranges in the million or more.

To this, add the fact that if you are working waterfall, the time you need to develop the code is actually a small part of the time needed to develop specifications and design. I would estimate a 2/3 time is for specs+design, and the remaining 1/3 goes in coding, maybe even more on the specs+design part. It is really time consuming.

So, track your estimate from the complexity, to the lines of code, consider the manpower you have and how much they can work in parallel, and add the overhead of specs+design, you will get a very rough estimate.

I suggest you the mythical man month. It is a fantastic book on this regard.

I've been programming as a consultant for years, and I adore my work, which involves a lot of object-oriented analysis and design of software systems using managed languages (ie. software engineering). But I'd like to get a doctorate eventually, and it bothers me that I never really "got" Computer Science theory. In university I only did marginally well in those courses because the way they were taught did not work for me. I learn by observing application of concepts, not rote memorisation.

An example of where I've overcome such a barrier before - I had a horrible first year. The professor (who I now know was barely qualified and an incompetent teacher) started with C++, teaching us procedural programming. Technically I'd learned what an object was, but it wasn't until I saw the application of object-oriented analysis and design (with design patterns and other structures such as linked lists) that I really understood what they were for.

How would I go about learning subjects such as compilers, programming language theory, and analysis of algorithms? What would be a good way to get started on those? For example, I'd like to write a compiler eventually (for fun) but I've no idea where to start. Anyone ever been in this situation? Any suggestions for tutorials, free online lecture videos or reference (Something like w3schools would be wonderful)?

(I'd like to add that browsing Stackoverflow has already taught me loads, but I'd like it to be a bit more formal : )

EDIT: Thanks all for the suggestions. I've marked an answer that works for me personally, but keep the answers coming : )

I like Sedgewick's "Algorithms" (isbn 0201066734 1988 604p) because it talks one through algorithms in a conversational style, and has good examples. See the reviews under Amazon. (There are many variant editions, multivolume C++ Java etc.)

(Added 2feb:) Althoough algorithms are fundamental and fun, they're rather remote — hiking in high country, not the daily traffic jam.
Bentley's "Programming Pearls" (isbn 0-201-65788-0 2000 239p pearls )
"is full of small case studies, real examples, and interesting exercises for learning about how to program".

For big team software projects, Brooks's "Mythical Man-month" (isbn 0201835959 2ed 1995 322p Amazon ) is a must:
"conceptual integrity of the product is critical". And citing Parnas on p. 221:

instead of teaching people that O-O is a type of design, and giving them design principles, people have taught that O-O is the use of a particular tool. We can write good or bad programs with any tool. Unless we teach people how to design ...

Finally, visualization / GUIs / UIs often have a lot of room for improvement. I don't know of a good introductory book in this area, on a par with the above; anyone else ?

I've inherited a lot of web projects that experienced high developer turn over rates. Sometimes these web projects are a horrible patchwork of band aid solutions. Other times they can be somewhat maintainable mosaics of half-done features each built with a different architectural style. Everytime I inherit these projects, I wish the previous developers could explain to me why things got so bad.

What puzzles me is the reaction of the owners (either a manager, a middle man company, or a client). They seem to think, "Well, if you leave, I'll find another developer, because you're expendable." Or they think, "Oh, it costs that much money to refactor the system? I know another developer who can do it at half the price. I'll hire him if I can't afford you." I'm guessing that the high developer turn over rate is related to the owner's mentality of "My ideas are always great ideas, and if you don't agree, I'll find another (possibly cheaper) developer who agrees with me and does what I want". For the owners, the approach seems to work because their business is thriving. Unfortunately, it's no fun for developers because they go AWOL after 3-4 months of working with poor code, strict timelines, and insufficient client feedback.

So my question is the following:

Are the following symptoms of a project really such a bad thing for business?

  • high developer turn over rate

  • poorly built technology - often a patchwork of different and inappropriately used architectural styles

  • owners without a clear roadmap for their web project, and they request features on a whim

I've seen numerous businesses prosper with the symptoms above. So as a programmer, even though my instincts tell me the above points are terrible, I need to take a step back and ask, "are things really that bad in the grand scheme of things?" If not, I will re-evaluate my approach to these Do I build long term solutions or band-aid solutions?

** At the risk of this post being closed as non-programming related, I'd like to argue that I think it is programming related because answers to this question will influence the way a developer approaches a project. He will have a better feel for how far in advance he should plan his development (ie. build short term or long term solution) knowing he may quit at any moment.

From one perspective, the attitude(s) you're quoting are understandable. Software development isn't cheap, and most people/businesses are trying to save money everywhere they can. However I think they're usually shooting themselves in the foot with this sort of behavior.

One suggestion for dealing with this is to get a copy of The Mythical Man Month and read the section on why adding more programmers to a late project will only make it later (it's the title - and second (in my copy) - essay). Many of the same ideas apply to replacing a developer ... except that if you're working solo, it's likely you may as well start over, as figuring out what the previous person did may take longer than starting from scratch. After you've read the essay, give a copy to anyone who's taking the attitude you cite and ask them to read it. No guarantee that it will help, but it's worth a try.

I work for an organization that is pretty much a start-up within a large corporation. The team has several database engineers, and a few software engineers (in the data mining field). We're growing at a fast rate, which puts the need to have an overall architecture strategy or technology roadmap (or compass) for the next few years. As a software engineer, I've been assigned the task to start off on bi-monthly meetings to lead that discussion. So, my question is, how do you kick-off your role as an architect? how do you start off an organization-wide architecture discussion? I started reading the book "97 Things Every Software Architect Should Know", but I'd like to hear more from your experiences. So, as an architect, how did you start?

Best regards,

This is less from experience and more from practical thinking. First of all it's difficult to define software architecture - a great reference to start is always 'design patterns explained' as this takes a non-software approach to understanding architecture.

Start looking at specific core issues of architecture such as

  • Commonality and variability
  • separation of concerns
  • aggregation over abstraction

Architecture is not about removing complexity rather it's about managing it. So start by understanding the issues that comprise complexity in the context of your project

Your question is a hard one because it touches on many areas: process, leadership, and software design (or architecture). I'm going to assume you have a standard process already, but if you don't then try one of the Agile processes. I'll talk about leadership and software architecture.

Leadership. Fred Brooks' great book, The Mythical Man-Month, talks about having a technical leader the way a surgical team has a leader. Personally, I like more collaboration than I see with doctors, so let's treat Brooks's surgical team as an extreme. Still, you need someone to technically coordinate who is doing what, things like allocating people to work in different parts of the system, deciding what the hardest (riskiest) parts are (so that they don't get deferred until they're expensive to change/fix), and make choices when the team disagrees. This kind of technical leadership is needed whether you are building software, cars, or pogo sticks.

Architecture/Design. The standard mantra is that "Every system has an architecture" but the corollary is that not every architecture is deliberately chosen. You may implicitly copy the architecture from your last project, say a 3-tier system. Or it may be pre-decided once you know you're using a framework like EJB. At the beginning of a project, you'll be making architectural decisions and some will be hard to change later. How will you persist data? Will you use a framework (eg Spring, EJB, RoR)? Will you process data incrementally or in batch?

Pretty much any architecture can be forced to meet your requirements. For example, you could use RoR to build an thermostat. But you'll have an easier time when your architecture is a good fit for the requirements. Sometimes you'll have requirements, such as low user interface latency, that can be helped out by a wise architecture choice, like using AJAX. So the beginning of your project is an opportunity to think about these things and get them right. (And this doesn't mean you go up to the mountain, think hard, then dictate your answers to the team -- here again I favor collaboration).

Don't be afraid to think about architecture up front, especially about ways it can help you avoid difficulties, but also don't try to decide everything in advance. You'll have trouble if one part of your team started using Ruby on Rails while another part started using EJB -- so make some technical decisions, the ones that are forced on you and the ones that will address your biggest risks.

One last thing: Early architecture discussions are a blessing and a curse. They are a blessing in that they get ideas out early and allow you to choose your design rather than blunder into it. But they are a curse in that everyone will have opinions, and it can be difficult to get them all pointed in the same direction (ie back to the need for technical leadership).

I recommend Chapter 12 of Applied Software Architecture for guidance on your question. The list of headings gives a good idea of its advice: Creating a vision, the architect as key technical consultant, the architect makes decisions, the architect coaches, the architect coordinates, the architect implements, the architect advocates. The 97 Things book you mention is more of a collection of pearls of wisdom rather than a cohesive guide to architecture.

George Fairbanks, Author of Just Enough Software Architecture

It seems to be an article of faith that top-flight programmers are several times as productive as mediocre programmers. Can anyone point to studies or reports which support this with hard data?

It's hard to find hard data on anything related to programming, but I'll second the suggestion by Shiraz Bhaiji that you look at Code Complete by Steve McConnell. You might want to look at the next book he wrote, Rapid Development, as well. It also has some statistics.

As comments above pointed out, you need a good definition of productivity. Some people say that experienced and inexperienced programmers both write about the same number of lines of code per day but experienced programmers keep more lines of code per day. The inexperienced programmers will spin their wheels and rewrite most of today's code tomorrow.

There's some reference on this point in The Mythical Man-Month; I don't have my copy with me right now to see if the information is well-sourced, though.

I am a really young software engineer/QA Team leader. I have been developing software for about 2 years and for 1 of those years I have also been the head of the QA team at a software development company. Currently I am still working as the QA team leader/software engineer for QA tools. Recently I have been invited to join a group of friends and associates who would like to start a software company. They want me to be the architect/tech lead of the software (a special chat client written in Java is all I can say about it). I am very good at learning under fire and I learn a great deal by doing. However, I worry that my lack of experience will cause the project to fail (or at least be developed poorly). So I am wondering would you suggest I take the position, do my best and learn as I go? Or would you suggest I refuse?

If you would suggest I take the position would you please provide one or to resources that would be good for a beginning Java Architect?

The mythical man month & Peopleware are the 2 books you NEED to read.

My intention here is to have a single thread of will-make-you-a-better-programmer-just-for-reading sort of articles or papers or really standup blog posts that the writer has put in a lot of effort to distill (anything that will take you less than a day to read). I don't have the time to dig through the giant information crypts of the internet (most of the time) so if we help each other by placing beacons on the good stuff, we can all save time.


  • influence (or atleast cause you to examine) your perspective / outlook on programming.
  • be technology-agnostic (not relevant only to a specific community of programmers).
  • not be a plug for a new architecture, product or methodology.
  • not tied to a specific Role that supports programming. (How to do better specs/UX/etc.)
  • not make my brain hurt. Target an intermediate-to-advanced audience without assuming the reader to be a wizard at math / calculus

I see we already have 'What are the best programming articles?' and there is some amount of overlap (atleast with the first page) _ I can't find words to articulate the difference that I want to convey. I guess the emphasis is here on the 'craft' aspect.
Hope enough people find this idea to be of some use and contribute.. or it gets voted/closed down and doesn't add to the noise.

The Mythical Man Month, while a book rather than an article, is essential.

In a workplace where many people (including management) feel long hours is the way to demonstrate commitment, what are effective arguments that such practices are harmful, not just to the team members themselves, but to the project itself?

I am familiar with - and I believe - the common arguments: the risk of burnout, compromised quality, insufficient attention to keeping our skills up and our code malleable. But what arguments are most persuasive? What is the most persuasive way to deliver them?

Update Thanks, everyone, for all the great links to data - it's helpful, but what I'm really after is what arguments will be persuasive to people who are deeply invested in the crunch-mode ethic. I think I need more than data to shake loose their preconceived notions.

Have a look at The Mythical Man Month, Peopleware, and Slack. Then cite the hard work and real numbers of those more credible than yourself.

Usually if there is a development task that takes 4 days, if you put 2 developers on it then it does not necessarily halve the overall development time i.e. instead of 2 days it will take a bit more than 2 days due to things like developer discussions, technical meetings, disagreements, dependencies etc. What is the "technical term" to describe this principle?

I guess this may be more of a project management question than a web development question.

Any help will be appreciated.


Thanks for the responses but you are all referring to a principle that applies to a project already late. I am referring to any stage in the project. Perhaps there is no such "law" or "term" that has been formally defined and it is one of those things that we are all informally aware of during projects without coining a term for it.......perhaps.

"The Mythical Man-Month" is the most used phrase applied to the concept, after a title of the famous Brooks's book which discusses it in detail.

The concepts is usually more pronounced/applicable in the latter stages of the project and when the amount of people is >2 (communication overhead between just 2 developers is not that much of a deal and MAY actually shorted the development by allowing clearer thinking from each one as results of the discussion - however, with growing # of developers, communication grows O(n^2).

I know very little about OOP, so maybe my question is silly, but still....

Can you access object-oriented (OO) API from procedural (non-OO) languages? For example, Win32 API is not OO, but I know there is a wrapper for C++ to make it OO. But is it possible to do it both ways?

I ask because I don't like OO languages; I learned C by programming microcontrollers, and OO languages just take the actual code away from you, and I worry that OOP is so popular that soon everything will become based on objects.

Let me approach this as one cranky old programmer from the 70's to another(?)

One common technique in the old days when we were writing a library was to have an "init" call that created some kind of "cookie" (usually a pointer or array index). Then we'd force the client to supply the cookie back to us on every other call to the library. That allowed us to do whatever bookeeping our library required (in a re-entrant manner) without bugging the client with all the implementation details. As a C programmer you should be very familiar with this style, because C uses it for all its file I/O, as did Unix. Microsoft liked to call them "handles" instead of "cookies". Unix called them "files" or sometimes "file handles".

A large amount of what OO languages do is to just add some extra syntax around this technique. Now instead of all your calls starting with LibnameCallname (cookie, ... they start with cookie.callname(.... But really, in a lot of ways this is just a syntax change to make things easier for us programmers (saves us typing that extra unneeded Libname on everything).

Now in a way, OSes (including Unix, which used the file as its basic paradigmn for damn near everything), are already OO, and have been OO for decades. How they handle OS calls is really just a linkage detail. It doesn't matter much to us as systems programmers, except that the linkages have to match. The only real problem with calling C++ from C isn't that its "OO". The problem is that C++ uses some custom name-mangling algorithm for its symbols, which not all C compilers can deal with.

In truth, there's a bit more to it than that. However, if someone were to write all their new OS calls in C++, you can bet the C compiler vendors would find a way to bridge the gap, so that you could call them in your comfy old LibnameCallname(cookie,... style from C.

What you are actually saying you don't like it seems to me is what Parnas first referred to back in 1972 as Information Hiding - The idea that developers can be more productive if the details about how the various parts of a program work are hidden from the other parts.

It was very contraversial at the time. Even as late as the early ninties I used to hear big arguments about it. Fredrick Brooks even argued against it in The Mythical Man-Month. (BTW: If you haven't read TMM-M, you need to.)

The thing is, almost nobody argues against it today. There is a reason for that. Even Fred Brooks admitted he was wrong twenty years later. From his esay titled, Parnas was Right, and I was Wrong about Information Hiding -

Parnas was right, and I was wrong. I am now convinced that information hiding, today often embodied in object-oriented programming, is the only way of raising the level of software design.

To be fair, both sides would agree that on very small systems (like, for instance, the embedded systems you have been playing with?) information hiding is not nearly as nessecary. It is only when systems start getting really large that a fully interconnected system will start falling down under its own weight. However, today most programs are that large. That's the main reason the arguments have ceased.

I'm trying to learn how to make my application has the same "face" in all files, the same pattern, but I do not know if this is the right thing to do.

I want know if the more correct in software development, is to limit the application to only one type of pattern.

For example, that's how my application looks like (just a piece)


'use strict'
var Server = require('./server');
var Api = {
 init: function() {


'use strict'
var Server = {
 init: function(command) {
  this.command = command;

  if (command === 'start') {

I'm using the "initializer object pattern" in all my application. So i'm avoiding decorator pattern, facade, everything.

Should i avoid or i can use more than one? If the right answer is use several, depending on the needs, i have other question. This doesn't make the maintenance more difficult? Is not make the code like a spaghetti?



I'm going to try explain again, this time with a bounty.

i already try to ask but seems that no one really can give me a concise answer.

I would like to know what are the secrets from making a good app, a good web app, talking about code appearance. I want know if I should maintain the same standard code throughout my hole application, if this is GOOD, or really doesn't matter.

For example, i have two EXAMPLES files


var server = require('./server');

var app = {
 init: function() {

module.exports = app;


var server = {
 init: function(env) {
  if (env === 'DEVELOPMENT') {
    // CODE
  } else {
    // CODE

module.exports = server;

In this case, i'm using one object with method init, which is the pattern that i'm using in my hole app..

Or it doesn't matter, i should write anything:

first object:

var server = require('./server');

var app = {
 init: function() {

module.exports = app;

than server as a function:

var server =function(env) {
  if (env === 'DEVELOPMENT') {
    // CODE
  } else {
    // CODE

module.exports = server;

I can give 100 of my points. it's incredible how i can't find a good answer for this particular issue.


Should I using other patterns?

No, you should not insist on a single pattern.

No design pattern books will ever advise you to use a single pattern. Just like you cannot chop all ingredients in one single way (are you going to dice the spaghetti?), you cannot organise all logic in one single pattern.

Sure, you can make all your Objects use the initialiser pattern, and don't use constructors at all. This is ok. Been there, done that. I like it.

But these objects can be used with Builder or Abstract Factory (if it make things simpler). As long as the builders/factories themselves have initialiser, and that they properly initialise the created objects, then your use of the initialiser pattern will be consistent. Outside of creational patterns, it is usually good to organise objects with structural and behavioural patterns. They do not conflict with initialiser at all.

For example, look at DOM. All nodes are created by the Document object - elements, text nodes, comments, even events. This is the Factory pattern.

Yet the Document object is also a Facade! From it you access the whole system's status, objects, data, you can even write to it! Every DOM operation starts from the Document, it is the Facade of the DOM system.

DOM nodes also implements multiple patterns. They are organised in Composite, let you listen to events with Observer and Command, and handle events in a Chain of Responsibility. They are certainly parsed by an Interpreter, DocumentFragment is a Proxy, svg elements are implemented as Decorators, and createNodeIterator obviously gives you an Iterator.

The point is, good object-oriented design will yield multiple design patterns as a result, intentional or not.

What are the secrets for good code appearance

I think the best looking code is the one that is easiest to understand to you, and the way you read code changes as you gain more experience.

For example my style is too condensed for most programmers, but to me it strikes a good balance. So do develop your own style - you are not me, and you are not yesterday's you either.

Remember this as we go through the styles.

At the lowest level we have coding style - most importantly indent and bracket.

This one is simple, pick the one you like and stick with it. There are language specific styles, and they are often good starting points. Configure your IDE's formatter so that you can format all your code with hotkey.

Above the code syntax we have comment style and naming convention.

Setting rules on comment is fine, sometimes it is necessary for documenting tools. Avoid too much comment in practice. You may also want to decide your namespace and your stand on naming function expressions.

Above these structures, we have logic conventions.

The same code logic can often be done in many ways, some more 'beautiful' than the others in your eyes. Look at this example.

I picked the second style on first sight: no duplicate, logic is sectioned cleanly, format is not my style but reasonable. But many programmers would prefer the first style: logic is plain as day, a few duplications is worth it. While abstract, this level is quite deep - present your logic the wrong way actually increase the chance an experienced programmer read it wrong.

Finally, we arrives at the level of design pattern, about as far as code beauty goes.

The key to keep your code structure beautiful, is using the right patterns at right level to consistently accomplish loose coupling and code reuse, while avoiding pitfalls and over-design.

There are quite some books about beautiful code, and then there are even more books about designing and implementing beautiful software. (Decide for yourself which are beyond your level.) Knowledge is as important as experience, and you can gain them only by spending your time to study, to write, and to revise/refactor your apps.

Feel free to change your mind as you explore and experiment with your code. Changing your mind is a good sign of learning.

But first, familiarise yourself with design patterns. Just don't forget, they are the generic result of applying object-oriented principals to common tasks. It is still up to you to do the design.

Design Patterns Are Not Silver Bullets.

I recently run the SLOCCount tool because I needed to estimate the number of lines in a large project.

This is what it showed:

Totals grouped by language (dominant language first):
python:        7826 (100.00%)

Total Physical Source Lines of Code (SLOC)                = 7,826
Development Effort Estimate, Person-Years (Person-Months) = 1.73 (20.82)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 0.66 (7.92)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 2.63
Total Estimated Cost to Develop                           = $ 234,346
 (average salary = $56,286/year, overhead = 2.40).

I'm not entirely sure how it comes up with all those estimates but one in particular threw me off, the Development Effort Estimate. I read about the COCOMO model but I'm still a bit lost.

What is the meaning of this estimate in simple words?

The Development Effort Estimate is a measure of how much time it might have taken to create the 7.8k lines of Python code.

If you believe in divisible man-months of effort, it would have taken one person about 21 months to produce (might be about right), or two people about 11 months (a bit optimistic), or three people about 7 months (quite optimistic). In practice, it doesn't scale linearly like that — and some tasks are indivisible. Putting 9 women to work to produce a baby in 1 month doesn't work, even though it takes 1 woman 9 months to produce a baby.

Is $56k really the average salary for a programmer these days?