Here goes the list, in a completely arbitrary order of personal preference:

“Design for Hackers” by David Kadavy

It all started, around August, with a conversation with Paul, my cousin from London, the founder of Zerofee; we were talking that while designers could easily find tutorials and documentation to learn about software development, it was much harder for developers to find material about design, at least to learn the basic concepts.

Somehow, David Kadavy must have heard us, and he came up the following month with this great book. I have recommended it to every one of my students since I read it; it is built like a computer book, with clear explanations, diagrams and lots of pictures; every concept is described in detail, including historical references and examples.

David provides a healthy introduction to design, going through subjects such as fonts, proportions, color theory, structure, grids, and much, much more.

I insist; this is a must read for any developer, particularly those who, like me, are self-taught and eager to expand their own possibilities.

“Steve Jobs”, by Walter Isaacson

The day Steve Jobs passed away I was in South Africa, giving some trainings in Johannesburg, precisely about iOS. I remember waking up, opening my copy of Echofon in my iPhone, and seeing lots of tweets with just an apple sign on them.

I said to myself, as I started to scroll downwards, that this was it. I sat on the edge of the bed, realizing that it was the end of a huge chapter for the computer industry.

That very same morning, I gave an introduction to iOS to some developers, and of course there was a special thing to that training. Somehow there was a legacy of the guy in every NSObject that we allocated in memory.

Later that same month, I went to the USA and landed in Newark. While waiting for my connecting flight, I was dragging my feet in the terminal, and the corner of my eye saw the book in the shelves of a bookstore.

I read it in about 5 days. There had not been a book that hook me as much as this one in ages.

I will not go as far as saying that this was the book of the year. I won’t add anything to what is already available online about it. It was, without any doubt, the most hyped book of the decade. And it is a surprisingly good one; not biased, very acid in some parts – I guess Jobs would not have liked reading some sections of it. I picture him throwing the book out of the window, outraged, while weeping at some chapters.

I admit, I’ve shed some tears in some parts. All in all, a very emotional piece, not to be missed.

“JavaScript Patterns”, by Stoyan Stefanov

2011 was the year of the mobile web. Not only because some analyst said so, but because the demand for mobile web solutions from companies has increased dramatically in one year. Also because the capabilities of smartphones have grown in such a way that today, web apps are a viable choice for consumers.

This means, by all standards, that JavaScript regains a preeminence on the web; longtime a language that was bashed and forgotten, JavaScript reappears in front of many developers as the instrument by which the mobile web becomes a reality.

This book is a perfect way to rediscover JavaScript; to forget the pain of the past, to see that it is a wonderful language that, as Crockford would say, was hugely misunderstood.

By the way, readers should have read Crockford’s “JavaScript: the Good Parts” before this book; Stefanov builds on top of that knowledge and provides the developer with a fresh bouquet of idioms and constructions that will be useful in every JavaScript project.

Finally, given the rise of Node.js in the past few years, reading it provides also with a solid background for the next wave of JavaScript frameworks hitting the market these days.

“Programming the Mobile Web”, by Maximiliano Firtman

Maximiliano is a genius. The guy has pulled the complete bible, the absolute reference, for everything that has to do with mobile web development. The book is a treasure of capabilities, comparisons, history, and nitty-gritty details about every possible mobile web browser in the planet.

How he does it, it’s his great mystery. After publishing this book, he came up with the great Mobile HTML5 site which, if you haven’t seen it yet, you should.

Even better, he’s argie like I am, and I’ve had the opportunity of inviting him to Zürich last year, to hear him talk about jQuery Mobile. Which reminds me of…

“jQuery Mobile: Up and Running”, again by Maximiliano Firtman

… his latest book; this time, Maximiliano tackled the hottest mobile framework of the moment. I’ve read the book in “early release” mode, prior to the final publication, and so far it looks very promising.

In this book, Maximiliano explains the core concepts of jQuery Mobile, the semantics and the capabilities of the framework, clearly explaining its strengths as well as its weaknesses.

I have learnt a lot about jQuery Mobile through this book, so I strongly recommend it to anyone interested in the subject.

“Mobile Design for iPhone and iPad”, by Smashing Magazine

A very nice and concise eBook by the great people of Smashing Magazine, with great tips and tricks about how to create UIs for the new generation of touchscreen devices. I’ve learnt a lot with this book.

“iPad at Work”, by Apple

Finally, a nice free eBook by Apple, very useful for explaining the iPad and its multiple capabilities to business people; I am personally seeing more and more iPads in enterprise contexts, so I think that this is an important (and small) title to read.

eBooks

By all means, it is clear that 2010 was the year of the eBook. Maybe it’s because of the iPad, but I’ve been consuming more and more eBooks, even if I still enjoy buying some classics in paper form. Kindle, iPad, iBooks, Nook, GoodReader, PDF, ePub, all of those names have shaped my way of reading last year.

But one of the most visible changes of switching to eBooks was the speed of reading; consuming eBooks is fast, much faster than reading normal books. I can’t say that I prefer one or the other; it’s simply different. But reading eBooks is faster than reading paper books. Probably there’s a warmth factor in paper books, which makes me enjoy them longer, I don’t know, but the fact is, in 2010 my book reading consumption has gone up in an alarming rate.

Reading as a Reviewer

Another big change in 2010 was that, for the first time, I’ve been asked to review a book before it’s published, as a technical reviewer; and boy, what a book: it was iPad Programming by Daniel Steinberg and Eric Freeman. I’ve started reviewing it when the iPad’s iPhone 3.2 SDK was still in beta, and I remember it was the first book I’ve read in iBooks on my iPad. It’s an awesome reference for iPhone developers who want to start developing apps for this (at the time) new device, providing both design and programming techniques.

Actually, I got the great chance to meet Daniel in person later during the DevDay for iPhone in London and Geneva later, and he’s not only a great author but now too a good friend of mine.

Physical Books

But not everything was eBooks in 2010; I’ve been buying paper books as well, which I love and enjoy a lot; my preferred, by all standards, is this gem called Cocoa Design Patterns by Erik Buck and Donald Yacktman, which I think is a mandatory read for any iOS or Mac OS X developer; it is probably one of the most important books ever written about Objective-C.

Buck and Yacktman are also the authors of the 2002 Cocoa Programming absolute reference I’ve talked about in 2005, so I’m not surprised that this new collaboration yields such an impressive volume.

Other gems I’ve read this year:

• REWORK by Jason Fried and David Heinemeier Hansson;
• Presentation Zen by Garr Reynolds;
• HTML5 For Web Designers by Jeremy Keith (A Book Apart).

More eBooks

Finally, the list of great eBooks I’ve read, in either ePub, PDF, Kindle or just plain websites, in no particular order:

• 17 Rules Successful Companies Use to Attract and Keep Top Talent by David Russo;
• Don’t Make Me Think! by Steve Krug;
• The iPhone Developer’s Cookbook by Erica Sadun, 2nd edition;
• iPhone and iPad Apps Marketing by Jeffrey Hughes;
• Practical Common Lisp by Peter Seibel, which I adapted to ePub format;
• _why’s poignant guide to Ruby by _why the lucky stiff, also available as ePub and PDF versions;
• 20 Things I Learned About Browsers and the Web by the Google Chrome team.

Last year’s language was Go, and the books, well, here we go:

• Software Engineering: Barry W. Boehm’s Lifetime Contributions to Software Development, Management, and Research
• The iPhone Developer’s Cookbook: Building Applications with the iPhone SDK
• Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders
• Core Animation for Mac OS X and the iPhone: Creating Compelling Dynamic User Interfaces
• Pragmatic Version Control Using Git
• The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich

Software Engineering: Barry W. Boehm’s Lifetime Contributions to Software Development, Management, and Research

Barry Boehm is a name that might not strike a chord immediately, but if you work in the software field, it should. He has been working non-stop for the past 50 years (that’s right, 50), discussing all kind of subjects related to the practice of software engineering. This book is a compilation of his most well-known papers, with subjects ranging from project management to components, from iterative techniques to developer productivity. The guy has written about all of it, and when you realize how right he was, you wish you had read those papers earlier in your career.

The iPhone Developer’s Cookbook: Building Applications with the iPhone SDK

Erica Sadun is a legend in the iPhone software engineering field. Her involvement with the iPhone developer community from the very beginning (during the dark times of jailbroken iPhones) has increased since the release of the official iPhone SDK in March 2008. Her articles on Ars Technica or The Unofficial Apple Weblog are epic, and her book could not be other than a masterpiece. Make no mistake: this is not a book for beginners (and, by the way, the second edition has recently been published) but it is the perfect companion for all of us who spend a life in Xcode and the SDK. I hope she will continue providing more editions of this book, particularly now that the iPad has been announced, and will be released soon.

Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders

O’Reilly has some very successful book series, like the “Head First” and the “Beautiful” ones. The latter, very similar in spirit and nature to the “At Work” series of books by Apress, provides a series of interviews to key industry players, in different fields, highlighting real-world experiences. This book takes this approach and brings an incredible series of war stories from organizations like IBM, Media Molecule or the NASA, told by Grady Booch, Tim O’Reilly, Cory Doctorow, Steve McConnell and, yes, even Barry Boehm. This book reinforced my belief that software is a social process, and I think that you will enjoy these stories about how many well-known products we use and love (or hate) every day have been brought to market, and how their teams struggled to stay together – or how they miserably failed.

Core Animation for Mac OS X and the iPhone: Creating Compelling Dynamic User Interfaces

The iPhone OS and Mac OS X both share a legacy of design, attention to detail and awesomeness that can be explained by the sole existence of a single set of APIs: Core Animation. This library allows developers to create stunning visual effects with great performance and with just a few lines of code. The rational use of animations is considered a huge usability win, bringing context awareness to users, helping them understand what’s going on their applications and providing feedback and a “real world” feel to software. Bill Dudney provides here a short yet complete introduction to the concepts behind Core Animation, both for the Mac OS X and iPhone OS; all in all a must have for all Cocoa and Cocoa Touch developers.

Pragmatic Version Control Using Git

I’ve been a happy Subversion user for years. I’ve kept svn repositories for my Master’s degree work, my personal documents and of course for most of my projects. However, the server-centric nature of Subversion always made me think twice before creating a repository, and not being able to browse repository contents without a specialized client was always a pain in the neck. Not to name the fact that branching in svn is harder than it should be IMHO. Git changed all of that. Creating repositories with Git is not only cheap, it’s easy and fast, and branching could not be easier. This book was the one that showed me that there was a better way, and now with my Github account, I can’t think of any other way to handle any kind of project. This book provided the initial knowledge to get started, and I strongly recommend it to anyone who wants to learn more about Git.

The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich

Tim Ferriss is a strange kind of guy. He comes up with this book and tells you that you are working too much, that having a boss is killing you, and that you should be sipping margaritas in the Caribbean instead. And then he proceeds to show you how to do it. This book is interesting in many aspects, the first of which is the irreverent tone and the complete faith the guy has in his method. I could not agree with everything he said but I have to agree with the fact that he’s really convincing. Tim believes in what he says and the book is a really funny one, and I can’t deny that reading it helped me take the final decision to start my own company. So, in any case, beware! This book is dangerous :)

1. Contact the most important people in some field.
2. Sit down and ask a similar set of questions to each one of them.
3. Record all the interviews and then write them down.
4. Publish the resulting book, usually with great reviews (such as this one).

This does not constitute, by any means, a new genre; but it’s certainly a fashionable one in your technical bookstore right now. At least Apress and O’Reilly have realized that this simple technique yields epic books.

I have already blogged about Founders at Work, thus it’s worth mentioning that Coders at Work (which I’m reading right now) has just been released. Both books share a similar structure (as well as a similar cover), and both are highly recommendable, with interviews of David Heinemeier Hansson, Steve Wozniak and Paul Buchheit for the first, and Donald Knuth, Joe Armstrong and Brendan Eich for the second.

On the other side, O’Reilly is very well aware of the force conveyed by this kind of books: their “/Theory/In/Practice” series of books has some gems which, I think, are really worth reading:

“Beautiful Code” features interviews with Brian Kernighan, Charles Petzold and Yukihiro Matsumoto; “Beautiful Teams” (already my preferred book for 2009!) features Tim O’Reilly, Barry Boehm and Grady Booch; finally, “Masterminds” has great interviews with Bertrand Meyer, Bjarne Stroustrup, James Gosling, Brad Cox and Anders Hejlsberg.

I think that the names of the interviewees, in each of the five books, speak for themselves. In all of them, I have found inspiration, advice, tips, humour, awe and enlightenment. The good thing being that, in most cases, you don’t need a Computer Science degree to read these books; it’s just a matter of empathy and sociology. Our world is driven by software, and the stories behind its construction are not only interesting, they are also important to understand the cost, the difficulty and the wonder that constitutes a piece of working software. These books are a way to approach the immense complexity of our society.

I really look forward to read more books of this kind! If I forgot to mention any other similar book, just leave the reference in the comments section below. I’d love to read your suggestions.

Winner: Geekonomics: The Real Cost of Insecure Software by David Rice

Runner-up: The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn’t by Robert I. Sutton, PhD

And 6 more:

• Software Estimation: Demystifying the Black Art by Steve McConnell
• Modern C++ Design: Generic Programming and Design Patterns Applied by Andrei Alexandrescu
• It’s Not How Good You Are, It’s How Good You Want to Be by Paul Arden
• RESTful Web Services by Leonard Richardson and Sam Ruby
• JavaScript: The Good Parts by Douglas Crockford
• Programming Collective Intelligence: Building Smart Web 2.0 Applications by Toby Segaran

Geekonomics: The Real Cost of Insecure Software

My big winner for 2008. If you don’t care about software quality (yet), or if you think that machines aren’t already in charge or our world, this book is for you. This has been one of the most hyped releases of 2008, and indeed, it can send a chill down your spine. Geekonomics is a lively catalog of software glitches and disasters, showing users as “crash test dummies”, describing a whole industry built upon “end user license agreements”, removing liabilities as no other industry has ever been capable of. Even the world of free and open source software is described with strong criticism.

Geekonomics sometimes feels like a desperate plea to apply Deming‘s Total Quality Management principles in the world of software.

The book is interesting in several fronts. David Rice pledges for the creation of standards of quality, as well as tightening the requirement for certification of practitioners. His views are based on the United States, describing the legal framework of “tort law”, the economic foundations of “incentives” for industries, and using comparisons with other economic sectors, particularly with the automotive industry. The book is academic yet entertaining, frightening but instructive, but sometimes falling on the side of sensationalism, in my opinion. I could even say that some of Rice’s proposals are downright impossible to achieve, given the particular characteristics of the software industry, and the situation of the legal system in other parts of the world.

In any case, even if I do not particularly agree with all of his views, David Rice is right to emphasize his point strongly, giving concrete proposals, and opening the debate: the book would not have had the same impact if it had been written mildly.

Geekonomics was enlightening: it made me think about the quality of my own work in a completely different way (and prompted me to talk about it at Lausanne’s 2008 Barcamp). I think that taking a time of introspection, and reading your own code with different eyes is required to realize that we are, as software developers, responsible for much of what is going on in the world. And this is the major contribution of this book.

The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn’t

Some of my former colleagues will chuckle when they see this entry, because I’ve flown from a previous job a couple of years ago because of a total, complete, utter, outright and unmitigated asshole. A complete control freak, self-proclaimed genius, irresponsible jackass, who was the reason why 5 people (including me) left the place in less than 3 months.

(Guys, feel free to leave comments below ;)

More seriously, in the software industry it’s common to see that great developers are, more often than not, shy or introverted. This fact, coupled with the Swiss’ legendary attitude of eternal conciliation and conflict avoidance, has the side effect of creating troubled workplaces all over the country. No wonder this book made the headlines last month in Switzerland. This is a huge problem which is only being revealed right now.

In any case, this book is, together with Peopleware, a gem of teambuilding and a real bag of tricks to avoid turnover and burnouts in your company. An absolute read to everyone involved in the creation of workplaces, in every possible industry.

Software Estimation: Demystifying the Black Art

This book should be a mandatory read for every software developer, in every company, all over the world. It is a true gem, and a book that will become a timeless classic.

How many times have you been asked to estimate a project? To provide a deadline? To approve an estimation done by someone else? This book starts by enumerating the problems related to estimation, including those related to the definition of the word “estimation”, the politics and the economics surrounding and defining what is accepted and required, and the common traps where all of us have stumbled upon at least once. Then it provides a catalog of common estimation methods, from the most obvious to the most complex ones, including a description of their relative drawbacks and benefits.

McConnell is the author of Code Complete (which I’m re-reading these days) and Rapid Development (which I plan to read soon). This guy knows what he’s talking about, and he provides all the data required to support his claims. I cannot stress this more: if you are a project manager, a developer, a tester, an architect, or deal with software projects in some uncanny way, you have to read this book.

Modern C++ Design: Generic Programming and Design Patterns Applied

I bought this book during the writing of my Master’s degree dissertation project. I had heard about it before, but since my project involved a lot of C++ template metaprogramming, I thought that the best idea was to check with the real experts. And boy, I’m happy I did.

This book goes beyond your common programming grounds, whichever your favorite language is. I personally enjoy writing C++ a lot, but that’s me, and your mileage may vary. Doing multiple inheritance mixed with template metaprogramming, however, stretches your mind into the realm of what you previously considered esoteric and impossible, and that’s precisely the kind of readings that take you a long way forward.

If you are looking for a new way to write your old C++ code, or if you are asking yourself how different are C++ templates from Java or C# generics, read this book. You’ll find a lot of interesting stuff in it, with explanations related to an existing library (written by the author) called Loki, which provides the implementation of several patterns explained in the book.

It’s Not How Good You Are, It’s How Good You Want to Be

This little book (less than 130 pages long) was written by Paul Arden, former creative director of Saatchi & Saatchi, a recognized advertising agency (whose “early growth was also helped by a policy of settling the invoices from small suppliers as late as possible, while promptly paying large, high-profile companies”, dixit their Wikipedia article. No comments.)

Paul Arden provides extremely interesting and pragmatic views on creativity, people management, client relationship management and other stuff; if you happen to work in a web or advertising agency, you should read this book. However, as a software developer, I think that many of his views are still applicable to our own activity, particularly when, like me, you’re beginning your own independent path. It is not always obvious how to deal with situations when you’re “in charge”, and Arden’s recommendations do help.

RESTful Web Services

For years I thought that SOAP was the way to go. And then some Rails activists started talking about RESTful this, RESTful that, and well, it tickled my curiosity. It all started with Roy Fielding‘s doctoral dissertation about network architectures, followed by all the buzz of Web 2.0 APIs, which in the case of most startups took the form of RESTful APIs, found to be much easier to document, use and maintain than their XML-RPC or SOAP counterparts.

I read this book because of a requirement of a project where I worked at the beginning of the year, and this led to several blog posts and even a project, that are still today quite popular. I’ve been using the RESTful approach for other projects, involving .NET, the iPhone and Cocoa on the Mac, and I would have never thought that doing network-based programming could be this fun. Looking backwards, attempts like SOAP and XML-RPC look clunky, adding layers of unneeded complexity for most projects, and creating a higher barrier of entry for new users of an API.

JavaScript: The Good Parts

Douglas Crockford is head of web development at Yahoo!, and probably the person in the world that knows most about JavaScript. I’ve been reading his articles since I started working in my Propano project, and then watching his videos as soon as they became available.

His views of JavaScript as the World’s Most Misunderstood Programming Language helped me see this (now I think) beautiful language under a new light. And of course, I could not miss reading his short (170 pages) but extremely detailed book. I thoroughly enjoyed it and strongly recommend its reading to anyone dealing with JavaScript in any way.

Programming Collective Intelligence

I love programming books focusing on solutions rather than on specific features of some language; they provide insight on how to solve problems, showing the mathematical background required to do it. This is one of them.

This book can be considered a practical handbook on statistics programming, using Python for the code examples, but providing all the required insight and theory required to understand the logic beneath every code bit. The focus on Web 2.0 applications is clear, and this book has helped more developers than the author might ever know. Social sites are the realm of networks, large numbers, big datasets and complex relationships, and the techniques described in this book can help developers get out more information about their databases. Ever wondered how LinkedIn finds out someone you might know? This book has the answer for you.

What about you?

I would be very pleased if you could leave, in your comments below, the reference to your own preferred books. I am sure I have missed some gems last year, but 2009 is just starting!

One of the most famous citations in the book is the one regarding the consequences of adding human resources to a late project; this article will provide a couple of thoughts about this assertion, and highlight some contrariwise opinions. The Mythical Man-Month

The second chapter of Brooks’ masterpiece is named exactly as the book, “The Mythical Man-Month”; the core argument of this chapter is that the most frequent factor of project failure is schedule and time estimation. Brooks states that this is due to the fact that

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming. When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned.

(Brooks, pages 16 & 17)

The final phrase of the above paragraph is often used as a graphical depiction of the nature and meaning of Brooks’ law. It implies the strong need for communication and integration existing in software projects; being social processes, software requires a strong network of communication between team members, allowing them to coordinate the inherent set of interdependencies that every project has.

After an interesting analysis of common time overrun situations, Brooks ends this chapter with the following conclusion, which contains the enunciation of the law itself:

Oversimplifying otrageously, we state Brooks’s Law: Adding manpower to a late software project makes it later. This is then the demythologizing of the man-month. The number of months of a project depend upon its sequential constraints. The maximum number of men depends upon the number of independent subtasks. From these two quantities one can derive schedules using fewer men and more months. (The only risk is product obsolescence.) One cannot, however, get workable schedules using more men and fewer months. More software projects have gone awry for lack of calendar time than for all other causes combined.

(Brooks, pages 25 & 26)

This “law” is known and cited throughout the industry as an example of a common pattern, observed once and again in different projects all over the world:

Fact 3: Adding people to a later project makes it later(…) Intuition tells us that, if a project is behind schedule, staffing should be increased to play schedule catch-up. Intuition, this fact tells us, is wrong. The problem is, as people are added to a project, time must be spent on bringing them up to speed.(…) Furthermore, the more people there are on a project, the more the complexity of its communication rises.

(Glass, page 16)

As a personal experience, I must say that the lecture of this book opened my eyes more than many, many other books. It is a funny read, but also an enlightening one: many anecdotes told by Brooks strangely correspond to my own experience, and this one is no exception. I have seen projects gone unfortunately late because of the simple fact of adding more people; and in one particular case, the project was cancelled altogether. These projects had several factors in common, though:

• Bad documentation, or lack thereof; the only way for newcomers to the project to know what was going on was interrupting the other developers, disrupting the current operations on the project; I think that a good set of documents, describing both the high-level architecture and the low-level APIs are needed for new developers to jump in and catch up. It’s maybe not enough, but a good leap forward anyway.
• Lack of architectural vision; projects that do not have an architect, providing vision and technical leadership to the team, are in my opinion exposed to problems when more developers join the project. The architect can act as a proxy person, guiding new developers while they familiarize themselves with the project, isolating other developers from this task.
• Bad project decomposition in components; if the system to be developed is sufficiently large, and the decomposition in components is not properly done, the overlap and extended communication paths among team members might affect the whole project negatively. A good decomposition breaks down the whole project in a set of smaller ones, with the corresponding set of interfaces, which brings the whole team to work separately on different subsystems. In these, the risk of getting later for adding manpower is reduced proportionally.
• Bad working conditions; I positively think that open spaces are a common disease in our industry. Teams working in open spaces suffer more of noise and visual distractions, and this is more evident when new team members join the project.

Criticism

However famous, Brooks’ law has had a good deal of criticism as well, regarding the specific characteristics of projects that might be affected in case that new people is assigned to them. The OS/360 project, which served as the basis for Brooks’ work, might not be similar to other projects, and as such, the law would not necessarily apply to them:

For Brooks’ Law to be true, the amount of training effort required from existing staff must be significant. The amount of effort lost to training must exceed the productivity contributed by new staff when they eventually become productive. (…) “Late” chaotic projects are likely to be much later than the project manager thinks–project completion isn’t three weeks away, it’s six months away. Go ahead and add staff. You’ll have time for them to become productive. Your project will still be later than your plan, but that’s not a result of Brooks’ Law. It’s a result of underestimating the project in the first place.(…) Controlled projects are less susceptible to Brooks’ Law than chaotic projects. Their better tracking allows them to know when they can safely add staff and when they can’t. Their better documentation and better designs make tasks more partitionable and training less labor intensive. They can add staff later in the project with less risk to the project.

(McConnell, 1999)

Scott Berkun gives a more concrete analysis on why the law could be wrong:

• It depends who the manpower is. The law assumes that all added manpower is equal, which is not true.
• Some teams can absorb more change than others. Some teams are more resiliant to change.
• There are worse things than being later. (…) That can be ok if you also get higher quality
• There are different ways to add manpower. (…) The more experience everyone has with mid-stream personnel changes, the better.
• It depends on why the project was late to begin with. (…) no amount of programming staff modifications will resolve the psychiatric needs of team leaders or the dysfunctions of executives.
• Adding people can be combined with other management action. (…) if you’re removing your worst, and most disruptive, programmer and adding one of your best, it can be a reasonable choice.

(Berkun, 2006)

And what about open source projects? Many of these (Linux, Apache, MySQL) are potentially among the biggest software projects ever undertaken, and they don’t appear to suffer o fthe problems pictured by Brooks’ law:

But proponents of open source and free software development, including Linux developers, are not completely satisfied with the Law. Most famously (among geeks at any rate), Eric Raymond in his “The Cathedral and the Bazaar,” declared Brooks’ Law obsolete, if not simply limited, saying “if Brooks’ Law were the whole picture, Linux would be impossible.” Although Raymond now says that he has somewhat modified his views or was misunderstood, some still would say he is given to oversimplifying and outrageousness himself. “I don’t consider Brooks’ Law ‘obsolete’ any more than Newtonian physics is obsolete; it’s just incomplete. Just as you get non-Newtonian effects at high energies and velocities, you get non-Brooksian effects when transaction costs go low enough. Under sufficiently extreme conditions, these secondary effects dominate the system — you get nuclear explosions, or Linux.”

(Jones, 2000)

Conclusion

So far, the discussion seems to be open. There might be a scale factor for projects, which in turn might expose them to be affected by Brooks’ law. I think that research is needed to arrive to a conclusion, even if it will be a statistical one.

Other important facts highlighted in the book are the “second system phenomenon”, the productivity advantage of using high-level languages, and the importance of building a prototype – “one to throw away”. I can only recommend this book to everyone interested in the field of software engineering (which I did in my own review of classic books in this blog: http://kosmaczewski.net/2005/11/20/my-bookshelf-part-iii/ )

References

Berkun, S.; “Exceptions to Brooks’ Law”, January 11th, 2006, [Internet] http://www.scottberkun.com/blog/2006/exceptions-to-brooks-law/ (Accessed June 8th, 2007)

Brooks Jr., F. P.; “The Mythical Man-Month – Essays on Software Engineering, Anniversary Edition”, 1995, Addison Wesley, ISBN 0-201-83595-9

Glass, R. L.; “Facts and Fallacies of Software Engineering”, Addison-Wesley, 2003, ISBN 0321117425

Jones, P.; “Brooks’ Law and open source: The more the merrier?”, IBM, May 1st, 2000, [Internet] http://www.ibm.com/developerworks/linux/library/os-merrier.html (Accessed June 8th, 2007)

McConnell, S.; “Brooks’ Law Repealed?”, IEEE Software, November/December 1999 [Internet] http://stevemcconnell.com/ieeesoftware/eic08.htm (Accessed June 8th, 2007)

[source:c]

include

class Gadget { public: void sayHello() const { std::cout << “Gadget!” << std::endl; } };

class Widget { public: void sayHello() const { std::cout << “Widget!” << std::endl; } };

template class OpNewCreator { public: T* create() { std::cout << “Using ‘new’: “; return new T; } };

template class MallocCreator { public: T* create() { std::cout << “Using ‘malloc’: “; void* buf = std::malloc(sizeof(T)); if (!buf) return 0; return new(buf) T; } };

template