Talk:Brooks' Law

From Citizendium
Jump to: navigation, search
This article is a stub and thus not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
To learn how to update the categories for this article, see here. To update categories, edit the metadata template.
 Definition "Adding manpower to a late software project makes it later"- Fred Brooks [d] [e]
Checklist and Archives
 Workgroup category Computers [Categories OK]
 Talk Archive none  English language variant American English

Initial structural and editorial comments

The article should begin with more context. Are you sure the reader will understand the concept of software engineering? If not, a link is appropriate, which I inserted.

I removed your initial explanation that Brooks' Law is in simple words, as it seems more straightforward just to state the Law. Don't worry about the technique I used to emphasize the quotation, but you do need to cite direct quotations such as Brooks' book.

A CZ article is not an essay, so doesn't have a conclusion. I find a good rule comes from journalism, a rule called "inverted pyramid". The most important information: who, what, where, when, why — comes at the top, and the level of detail gets finer and finer as you move downward to the point of the inverted pyramid.

If you use specific examples, such as the one from Apple, cite it.

May I point out that this is Citizendium, where Wikipedia is sometimes gently called The Other Place, and, certainly, citing it as an authority, without even citing the article that contains the assertion, may be less than ideal? Howard C. Berkowitz 23:00, 27 July 2008 (CDT)

Additional commentary and some content, or links thereto

Be sure to explain new concepts, such as software project management, if you can't be sure the reader will understand them. It's quite acceptable if there is no article on that subject; creating the link to it will remind someone that it should be written.

While I still have Brooks' original book somewhere, next to me is the 20th Anniversary addition, where he discusses a good deal of history. I haven't tried to change your flow of headings, although I've added some material. Brooks originally proposed BDUF/waterfall, to which the Agile Manifesto people responded with a very different approach, of which one example is extreme programming (XP). XP is one of many approaches, and, when not done well, is just a faster way to get into trouble than BDUF.

The Pareto Principle is a fundamental idea in economics that has turned out to be insightful in software engineering. I have an unpublished discussion that I'll adapt to CZ format in the next day or so, if I don't do it tonight.

One of your first headings is examples, but I'm confused what you have in mind. Examples of Brooks' Law being true, or examples of how it was formally validated (start at [age 283 of the Anniversary Edition, with work by Boehm, Abdel-Hamid & Madnick, etc. The Apple case study needs some citations, or even a CZ article.

wince Wikipedia is not the place I look for possible solutions. While it can be argued that Wikipedia itself is a solution in search of a problem, if you look through Wikipedia policy, there's a rule somewhere that says Wikipedia is not an authoritative source to be cited for Wikipedia articles. In any event, as someone that has done a lot of direct software engineering as well as managing software engineering projects, I honestly don't understand the proposed solution, and why a project using it might not be late.

I did put in a major heading to introduce XP, because XP is a subset of Agile methods. So far, I have not been impressed by the people with whom I've worked, that claim to be doing XP. XP can be disciplined, with, at a minimum, some basic writeups of use cases. Some alleged XP experts seem to be of the opinion that XP means never having to write anything except code.

You don't need a conclusion in an encyclopedia-style article.

Howard C. Berkowitz 23:17, 27 July 2008 (CDT)