Slashdot Mirror

alphuris writes "CNN.com has a little nugget of info about Carl Sagan being an avid Marijuana user. Apparently Marijuana's effects were a good part of Sagan's motivation to write his books and do his research. Who says Marijuana's a downer?" The article also says, "Ann Druyan, Sagan's former wife, is a director of the National Organization for the Reform of Marijuana Laws. The nonprofit group promotes legalization of marijuana."

mediageek writes "Targeted at non Linux users, James Hills has written an editorial which tries to explain open source, why there are different distros and general Linux pros & cons. " This is a good one to pass on to your bosses/parents/friends - heck, all of the unwashed. *grin*

AT writes "Cygnus has released the source for a new x86 backend for gcc. The new code focuses on better PII optimization. Intel contracted the changes from Cygnus. The code isn't quite release quality yet, but it should be intergrated into gcc 2.9x source tree around August. " Hopefully this won't be an isolated incident considering the number of chips coming outta Intel in the not-so-distant-future.

Jason Bennett has sent us a review of one of the O'Reilly staples, UNIX in a Nutshell. Click below to read more. UNIX in a Nutshell author Daniel Gilly pages publisher O'Reilly rating 9/10 reviewer Jason Bennett ISBN 1-56592-001-5 summary One of the most comprehensive UNIX handbooks on the market, and certainly one of the favorite. The ultimate reference, although not recommended for learning UNIX. Background

Greetings, all. This week I'll be "reviewing" one of the books that made the O'Reilly name, UNIX in a Nutshell, although I admit to feeling a little silly passing judgement on a book that has already been judged quite well by the community at large. The first edition of this book was published in December 1986, and has been a mainstay ever since. This particular version is dated June 1998, and professes to include typographical fixes and a new index. For reference, in December 1986 I was working on an IBM PCjr expanded to 640k of RAM and dual 360k floppy drives. My favorite games were Karateka, Flight Simulator II and F-15 Strike Eagle (the first one). How far we've come....

What's the book about?

Simply put, this book is a dictionary of UNIX. It lists every command available with a standard System V, Release 4 or Solaris 2.0 UNIX. This included everything from grep to ed to cc to troff. If you know a command exists, it's listed here along with all its options. That, however, is but a small part of the book. In addition, there are various specific sections covering shells (including sh, ksh and csh), EMACS, vi, ex, awk, sed, nroff/troff, mm/ms/me, various nroff/troff preprocessors, RCS/SCCS, make, sdb/dbx, plus a small beginner's list of important commands. In other words, this is the jack of all trades reference for UNIX (and by extension, the master of none, although I'll cover that later). There is also a transition guide (or at least a small blub) for those used to BSD instead of SysV (of which Linux is a decendent of the later). Many BSD commands included in /usr/ucb on Solaris are listed in the guide as well. In short, if it's standard UNIX (and then some), it's here.

What's Good?

If you want a kitchen-sink reference to UNIX, this is it. Any command that you have a question about is in here. Anytime you have a question about which vi command is needed, it's in here. Shell scripting is covered. Regular expressions are covered, for when you forget when to use "?" and when to use "*" (or "^" or "$"). Want a quick overview to RCS for your web files? It's right here. This is the short, short version of all your man pages that you can put under your pillow at night.

What's Bad?

If you don't know much or anything about UNIX, don't buy this book. Or at least buy an introductory one along with it. Trying to learn UNIX from this book is like trying to learn English by reading the dictionary. Not only is there not much context, you can't do a reverse lookup. If you can't guess at the command you want, you won't be able to find it. That's not necessarily a flaw, this book just wasn't designed to do that. You don't buy the OED for a Spanish speaker, and you don't buy UNIX in a Nutshell for a newbie. In addition, don't buy this book just for its EMACS or vi or RCS section. Those sections are nice, but they are more command lists than guides. O'Reilly has an excellent selection of books dedicated to helping you with one of the above programs. They're great, and I recommend them.

What's In It For Us?

Long-time UNIX fans will love this book, and probably already own a copy. Same with sysadmins. If you've been around enough to know what you're doing, but still have to look up commands, this is also a great book for you. I know I can never remember half the EMACS or vi commands when I need them. The community has voted, and this reference is it. If you need it, buy it.

Buy the book at Amazon.

Jason Bennett has sent us a review of one of the O'Reilly staples, UNIX in a Nutshell. Click below to read more. UNIX in a Nutshell author Daniel Gilly pages publisher O'Reilly rating 9/10 reviewer Jason Bennett ISBN 1-56592-001-5 summary One of the most comprehensive UNIX handbooks on the market, and certainly one of the favorite. The ultimate reference, although not recommended for learning UNIX. Background

Greetings, all. This week I'll be "reviewing" one of the books that made the O'Reilly name, UNIX in a Nutshell, although I admit to feeling a little silly passing judgement on a book that has already been judged quite well by the community at large. The first edition of this book was published in December 1986, and has been a mainstay ever since. This particular version is dated June 1998, and professes to include typographical fixes and a new index. For reference, in December 1986 I was working on an IBM PCjr expanded to 640k of RAM and dual 360k floppy drives. My favorite games were Karateka, Flight Simulator II and F-15 Strike Eagle (the first one). How far we've come....

What's the book about?

Simply put, this book is a dictionary of UNIX. It lists every command available with a standard System V, Release 4 or Solaris 2.0 UNIX. This included everything from grep to ed to cc to troff. If you know a command exists, it's listed here along with all its options. That, however, is but a small part of the book. In addition, there are various specific sections covering shells (including sh, ksh and csh), EMACS, vi, ex, awk, sed, nroff/troff, mm/ms/me, various nroff/troff preprocessors, RCS/SCCS, make, sdb/dbx, plus a small beginner's list of important commands. In other words, this is the jack of all trades reference for UNIX (and by extension, the master of none, although I'll cover that later). There is also a transition guide (or at least a small blub) for those used to BSD instead of SysV (of which Linux is a decendent of the later). Many BSD commands included in /usr/ucb on Solaris are listed in the guide as well. In short, if it's standard UNIX (and then some), it's here.

What's Good?

If you want a kitchen-sink reference to UNIX, this is it. Any command that you have a question about is in here. Anytime you have a question about which vi command is needed, it's in here. Shell scripting is covered. Regular expressions are covered, for when you forget when to use "?" and when to use "*" (or "^" or "$"). Want a quick overview to RCS for your web files? It's right here. This is the short, short version of all your man pages that you can put under your pillow at night.

What's Bad?

If you don't know much or anything about UNIX, don't buy this book. Or at least buy an introductory one along with it. Trying to learn UNIX from this book is like trying to learn English by reading the dictionary. Not only is there not much context, you can't do a reverse lookup. If you can't guess at the command you want, you won't be able to find it. That's not necessarily a flaw, this book just wasn't designed to do that. You don't buy the OED for a Spanish speaker, and you don't buy UNIX in a Nutshell for a newbie. In addition, don't buy this book just for its EMACS or vi or RCS section. Those sections are nice, but they are more command lists than guides. O'Reilly has an excellent selection of books dedicated to helping you with one of the above programs. They're great, and I recommend them.

What's In It For Us?

Long-time UNIX fans will love this book, and probably already own a copy. Same with sysadmins. If you've been around enough to know what you're doing, but still have to look up commands, this is also a great book for you. I know I can never remember half the EMACS or vi commands when I need them. The community has voted, and this reference is it. If you need it, buy it.

Buy the book at Amazon.

Barbarian writes "This article at 3D Action Planet discusses the possibility of a Software regulatory body, with the power to impose fines on companies which release crashware. Although the article ignores Open Source, it is insightful in it's assesment of commercial software. The article pertains towards games, but it is intended to apply to the Software industry in general. " My only question: Much like the UN, where does the real power come from; how do the fines stick, and actually get paid?

AT writes "The new Mozilla Gecko display engine has been embedded into a GTK widget. This means that you can embed webpages into your application, just like you might with an ActiveX control under Windows. " Can I embed mozilla in mozilla yet?

Mockingbird writes "The Associated Press is reporting today that Burger King plans to offer internet access from up to 20 workstations at a franchise in Hartford, CT. Value meal purchasers get 15 free minutes, but no porn and no e-mail. Have it your way, indeed. " If I mega size it can I have a half hour?

PowerPC sent us a post from 3dfx.glide.linux asking for someone interested in working at 3dfx. Specifically to work on developing, evangelizing and maintaining 3dfx under Linux. Glad to see another vendor joining the fray. I've attached the full request and contact information below.
From: Marty Franz <mfranz@141.com>
Newsgroups: 3dfx.glide.linux
Subject: Linux Job Opening at 3dfx
Date: Thu, 06 May 1999 20:35:58 -0700
Organization: 3Dfx Interactive
Reply-To: mfranz@141.com

All,

I'm looking for a hard core Linux/3D programmer to join the Voodoo Porting Group at 3dfx. This person must live/eat/breath Linux and 3D graphics. Imagine working all day every day in Linux....Sound cool ? Think you have what it takes ? Email your resume to the email address below.

Voodoo Porting Group Job Description

- Answer developer questions in a timely manner.
- Evangelize 3D API?s and 3dfx hardware to developers.
- Develop tools to ease development on 3dfx platforms.
- Develop 3D demos and technologies to promote the use of advanced graphic techniques.
- Help maintain and improve the quality of 3dfx software distributions.
- Develop and present technical presentations at 3dfx developer conferences.
- Help maintain 3dfx developer web site.
- Publicly promote 3dfx and the use of 3dfx hardware under Linux.

Skills Required

- Strong C/C++ experience required. Assembly experience a plus
- Must have a minimum of one year 3D graphics experience.
- Glide and OpenGL experience a plus.
- Strong math background a plus.
- Strong written and verbal skills required.

Marty.

--
Marty Franz
Director of VPG
3Dfx Interactive, Inc.
mfranz@3dfx.com

Lo, the reviewing hero has returned: Jason Bennett has returned with a review of Mark Harrison and Michael McLennan's effort Effective Tcl/Tk Programming. Designed as a book for those going deeper with their Tcl/Tk knowledge, this book works for those of you beyond the introductory page. Click below for more information. Effective Tcl/Tk Programming author Mark Harrison and Michael McLennan pages publisher Addison Wesley Publishing Company, Inc. rating 8/10 reviewer Jason Bennett ISBN 0-201-63474-0 summary A book for advanced Tcl/Tk programmers with thorough examples and good tips. As with most advanced books, it's probably better as a reference book than for pure reading, but its coverage is thorough enough to teach most Tclites a few tricks. Background

Greetings, all, I'm back once again. After my travels into the world of Tk a few weeks ago, I've branched out to include its sibling, Tcl, in all its glory. Tcl, I have to say, reminds me a lot of Lisp, at least in its typelessness and fondness for lists. I do miss all the (()), though :-).

What's the book about?

Generally speaking, it is designed as a sequel to any and all introductory Tcl books with a view toward more advanced and narrow concepts. The authors go through various parts of Tcl that the novice programmer might not use frequently, but the advanced programmer will find quite useful. The geometry managers are all covered in detail, so the advanced programmer can select the best one. The canvas widget, that all-purpose blank slate, is given quite a bit of room. The book even covers communicating with other programs on the same machine and through sockets. Most all aspects of Tcl and Tk are addressed to some extent, leaving few stones unturned. Of course, programmers on different levels and with different experiences will find different nuggets in here. Personally, I was well acquainted with the text widget, making chapter five somehwat redundant, but needed some help with communicating with other processes. YMMV. Generally, the book is composed of several large examples, with new features added in each chapter. There certainly is a great deal of code, relative to the amount of explanation, so a good grasp of Tcl is required. In addition, the final chapters deal with delivering a complete, cross-platform Tcl application to the marketplace, in terms of packaging and cross-platform compatability. There's a nice install program example, and plenty of cross-platform minefields mentioned.

What's Good?

This book is excellent for any Tcl programmer who's looking to add one of the skills covered in this book to his bag o'tricks. If you want to know more about text widgets, or using Tcl as a front-end to other programs, there's plenty of explanation and example to glean from this book. If you want to know more about general Tcl concepts like the event loop or the geometry manager, there's still more for you. There are also plenty of concepts addressed that could be applied to other GUI efforts outside of pure Tcl/Tk. I wouldn't necessarily read the book just for those, but they are a welcome addition. The examples in particular are quite thorough, with extra code available that is not printed in the book. There's even an entire calander manager written that's quite full-featured. Any topic covered comes with not only text but plenty of code. Commercial Tcl developers will especially appreciate the emphasis on professional Tcl libraries and delivery. If you do Tcl for a living, you'll appreciate this book.

What's Bad?

If you don't want to delve deep into Tcl, don't bother with this book. You'll end up having to deal with areas of the language you never wanted to know, and you'll end up frustrated. Similarly, I wouldn't recommend reading this from beginning to end unless you love Tcl. There are plenty of parts where the flow is bogged down by the endless obscure code, and if you aren't interested, you'll end up skipping it anyways. Skim the parts that you don't need now, and come back to them.

What's In It For Us?

Since I know there are plenty of Tcl fans out there, I'm sure there will be plenty of interest in this book. As I said, if you're just starting with Tcl, hold off on this one. If, however, you've honed your Tcl skills, but need some extra help in some areas, this book is for you. Whether you're into sockets with Tcl or just want to use that text widget more effectively, you will find this book useful. I'm sure it will be coming off the shelf for reference much in the future.

To purchase this book, head over to FatBrain.com, and pick it up.

Lo, the reviewing hero has returned: Jason Bennett has returned with a review of Mark Harrison and Michael McLennan's effort Effective Tcl/Tk Programming. Designed as a book for those going deeper with their Tcl/Tk knowledge, this book works for those of you beyond the introductory page. Click below for more information. Effective Tcl/Tk Programming author Mark Harrison and Michael McLennan pages publisher Addison Wesley Publishing Company, Inc. rating 8/10 reviewer Jason Bennett ISBN 0-201-63474-0 summary A book for advanced Tcl/Tk programmers with thorough examples and good tips. As with most advanced books, it's probably better as a reference book than for pure reading, but its coverage is thorough enough to teach most Tclites a few tricks. Background

Greetings, all, I'm back once again. After my travels into the world of Tk a few weeks ago, I've branched out to include its sibling, Tcl, in all its glory. Tcl, I have to say, reminds me a lot of Lisp, at least in its typelessness and fondness for lists. I do miss all the (()), though :-).

What's the book about?

Generally speaking, it is designed as a sequel to any and all introductory Tcl books with a view toward more advanced and narrow concepts. The authors go through various parts of Tcl that the novice programmer might not use frequently, but the advanced programmer will find quite useful. The geometry managers are all covered in detail, so the advanced programmer can select the best one. The canvas widget, that all-purpose blank slate, is given quite a bit of room. The book even covers communicating with other programs on the same machine and through sockets. Most all aspects of Tcl and Tk are addressed to some extent, leaving few stones unturned. Of course, programmers on different levels and with different experiences will find different nuggets in here. Personally, I was well acquainted with the text widget, making chapter five somehwat redundant, but needed some help with communicating with other processes. YMMV. Generally, the book is composed of several large examples, with new features added in each chapter. There certainly is a great deal of code, relative to the amount of explanation, so a good grasp of Tcl is required. In addition, the final chapters deal with delivering a complete, cross-platform Tcl application to the marketplace, in terms of packaging and cross-platform compatability. There's a nice install program example, and plenty of cross-platform minefields mentioned.

What's Good?

This book is excellent for any Tcl programmer who's looking to add one of the skills covered in this book to his bag o'tricks. If you want to know more about text widgets, or using Tcl as a front-end to other programs, there's plenty of explanation and example to glean from this book. If you want to know more about general Tcl concepts like the event loop or the geometry manager, there's still more for you. There are also plenty of concepts addressed that could be applied to other GUI efforts outside of pure Tcl/Tk. I wouldn't necessarily read the book just for those, but they are a welcome addition. The examples in particular are quite thorough, with extra code available that is not printed in the book. There's even an entire calander manager written that's quite full-featured. Any topic covered comes with not only text but plenty of code. Commercial Tcl developers will especially appreciate the emphasis on professional Tcl libraries and delivery. If you do Tcl for a living, you'll appreciate this book.

What's Bad?

If you don't want to delve deep into Tcl, don't bother with this book. You'll end up having to deal with areas of the language you never wanted to know, and you'll end up frustrated. Similarly, I wouldn't recommend reading this from beginning to end unless you love Tcl. There are plenty of parts where the flow is bogged down by the endless obscure code, and if you aren't interested, you'll end up skipping it anyways. Skim the parts that you don't need now, and come back to them.

What's In It For Us?

Since I know there are plenty of Tcl fans out there, I'm sure there will be plenty of interest in this book. As I said, if you're just starting with Tcl, hold off on this one. If, however, you've honed your Tcl skills, but need some extra help in some areas, this book is for you. Whether you're into sockets with Tcl or just want to use that text widget more effectively, you will find this book useful. I'm sure it will be coming off the shelf for reference much in the future.

To purchase this book, head over to FatBrain.com, and pick it up.

Squeezer sent us the April Edition of ext2 and Jim sent us the April Edition of FreeBSDZine . For the obsessive, Evan Vetere sent us a link to the Amazon preorder form for novelizations of the prequels. Its a 4 book set: 4 different covers, but 4 copies of the same book. Doommaker sent us linkage to info about that other cool movie coming out: Southpark is also gracing the big screen. bjb sent us a link to a applet that will Shred Any Web Page. Particular cheering after a long unsuccessful day. DaMan Penguin Pez Well, its the season for Peeps, and Italica sent us a url to a page of fun things to do to your leftover marshmellow bunnies. Not enough candy torture? frohike writes sent us another one. What did those bunnies do to deserve this? An anonymous reader alerted us to www.fishdot.org. Wierdos. Finally, an another anonymous reader sent us the most Hilarious Attorney Page Ever. Its for Leonard Crabs, Attorney At Law. "If your legal case is not won within 24 days, we''ll buy you a free combo meal at Taco Bell." Go now. Its funny.

BobRainGod wrote in to tell us that a fire has apparently wasted Apple's Mexican production plant, and stunted iMac production. No this doesn't have anything to do with the APSL.

After a bit of a hiatus, Jason Bennett has returned with a review of Nancy Walsh's Learning Perl/Tk. As the title of the book would indicate, this is an ideal book for those looking to learn the Tk tool kit and Perl. This book assumes a level Perl background, and a little GUI, but is a good intermediate step-click below if you want to know more. Learning Perl/Tk author Nancy Walsh pages publisher O'Reilly rating 8/10 reviewer Jason Bennett ISBN 1-56592-314-6 summary A solid introduction to using the Tk toolkit with Perl. If you have a reasonable Perl background, and a little GUI on the side, you'll pick it up in no time. Background

Greetings, all. This will be the first in a series of reviews dealing with some Tcl/Tk books I've recently acquired. Since I already have some Perl in my background, I took this one first, both to sharpen my Perl skills, and to find out what this Tk thing is all about. Given that my GUI experience is limited to Smalltalk and Java, Tk is quite easy to use. With Smalltalk, I was too busy wrapping myself around OO theory to enjoy the interface, and Java always seemed to make GUI stuff more difficult than it needed to be (although I still love it). Perl and Tk are strong partners, because they share a philosophy of getting things done without a lot of fuss. Perl and Tk are excellent replacements for any GUI scripting language you might use (read: VB). Read on to see how to jump in!

What's the book about?

This is another book in O'Reilly's Learning series (of which Learning Perl really saved my butt in college), which is dedicated to teaching the fundamentals of a certain topic. I want to compare this series with the Learn XY in 21 days type of books, although I believe that would generally be an insult to the quality of O'Reilly. Once you finish this book, you will have enough of an understanding of Tk to be able to do most small projects. You will know most widgets (although I'll admit my own knowledge is limited here), and will generally be prepared to be productive with Tk in Perl.

What's Good?

In order for you to be able to evaluate the usefulness of this book, it will probably help to understand where I'm coming from. I have a BSCS from Georgia Tech, and have enough languages under my belt to do some damage (Lisp is cool!). In fact, I learned Perl originally for a networking project using Learning Perl. It gave me enough to do what was needed. Having said that, I don't live to program, and in fact I'm not big on reading language books. I don't know every language under the sun, and I don't necessarily learn them with the greatest of ease. In other words, my results should be duplicable by most programmers. The most important thing when reading this book is to know Perl (at least have written some stuff in it), and probably have an idea of what to expect when writing GUI code.

Going into this, my Perl was definitely rusty (having not touched it in a while). I didn't have any trouble diving straight in, however. The Perl constructs used are not overly complicated, and my knowledge was sufficient. (NOTE: make sure you have a very recent version of Perl installed. My Redhat 5.2 needed to be upgraded to m4 before the examples would work. Also, get the errata from O'Reilly.) The early chapters deal with basic constructs and widgets, and spend a great deal of time on the geometry managers (go figure). Each chapter introduces a new widget, although some are used before they are introduced (just nod and smile when you see those and don't worry). There are plenty of examples, code fragments, and exercises to keep anyone busy. I tried to work as many as I could, to get a feel for the language, and generally felt like they were helpful. I never felt completely lost or confused, and generally followed things without much trouble. Having finished the book, I feel confident that, given a little work on my Perl, I could write a useful application with Tk, especially given some research on CPAN for various contributed modules. For me, the book worked.

What's Bad?

Nothing in this book is particularly bad, although there are a few nits I'd like to pick. First, the early emphasis on geometry was somewhat interesting. I'm not sure why I care about grid vs pack when I can barely create a button to put on the screen. For that matter, frames are referenced in a short chapter late in the book, after being used all throughout. If the concept is so basic, why not put it toward the beginning? Also, there were times when the author mentions that an option is esoteric, or generally unused, and then spends much more time than necessary on that point. If it's so esoteric, why is it being covered in a basic book like this one? Finally, there were a few times that the book did not explain a point well enough to me, and I had to divine the answer down the road (like configuring scrollbars). It was not a major issue, but there were some things that could have been clearer.

What's In It For Us?

If you want to learn Tk using Perl, this book will let you do that. It gives a solid introduction to the topic, and on completion, you will be a useful Perl/Tk programmer. Just know your Perl going in, and you will be fine.

Purchase the book over at Computer Literacy.

1. Preface
   
2. Introduction to Perl/Tk
3. Geometry Management
4. The Basic Button
5. Checkbuttons and Radiobuttons
6. Label and Entry Widgets
7. Scrollbars
8. The Listbox Widget
9. The Text Widget
10. The Canvas Widget
11. The Scale Widget
12. Menus
13. Frames
14. Toplevel Widgets
15. Binding Events
16. Composite Widgets
17. Methods for Any Widget

1. Configuring Widgets with configure and cget
2. Operating System Differences
3. Fonts
   Index

After a bit of a hiatus, Jason Bennett has returned with a review of Nancy Walsh's Learning Perl/Tk. As the title of the book would indicate, this is an ideal book for those looking to learn the Tk tool kit and Perl. This book assumes a level Perl background, and a little GUI, but is a good intermediate step-click below if you want to know more. Learning Perl/Tk author Nancy Walsh pages publisher O'Reilly rating 8/10 reviewer Jason Bennett ISBN 1-56592-314-6 summary A solid introduction to using the Tk toolkit with Perl. If you have a reasonable Perl background, and a little GUI on the side, you'll pick it up in no time. Background

Greetings, all. This will be the first in a series of reviews dealing with some Tcl/Tk books I've recently acquired. Since I already have some Perl in my background, I took this one first, both to sharpen my Perl skills, and to find out what this Tk thing is all about. Given that my GUI experience is limited to Smalltalk and Java, Tk is quite easy to use. With Smalltalk, I was too busy wrapping myself around OO theory to enjoy the interface, and Java always seemed to make GUI stuff more difficult than it needed to be (although I still love it). Perl and Tk are strong partners, because they share a philosophy of getting things done without a lot of fuss. Perl and Tk are excellent replacements for any GUI scripting language you might use (read: VB). Read on to see how to jump in!

What's the book about?

This is another book in O'Reilly's Learning series (of which Learning Perl really saved my butt in college), which is dedicated to teaching the fundamentals of a certain topic. I want to compare this series with the Learn XY in 21 days type of books, although I believe that would generally be an insult to the quality of O'Reilly. Once you finish this book, you will have enough of an understanding of Tk to be able to do most small projects. You will know most widgets (although I'll admit my own knowledge is limited here), and will generally be prepared to be productive with Tk in Perl.

What's Good?

In order for you to be able to evaluate the usefulness of this book, it will probably help to understand where I'm coming from. I have a BSCS from Georgia Tech, and have enough languages under my belt to do some damage (Lisp is cool!). In fact, I learned Perl originally for a networking project using Learning Perl. It gave me enough to do what was needed. Having said that, I don't live to program, and in fact I'm not big on reading language books. I don't know every language under the sun, and I don't necessarily learn them with the greatest of ease. In other words, my results should be duplicable by most programmers. The most important thing when reading this book is to know Perl (at least have written some stuff in it), and probably have an idea of what to expect when writing GUI code.

Going into this, my Perl was definitely rusty (having not touched it in a while). I didn't have any trouble diving straight in, however. The Perl constructs used are not overly complicated, and my knowledge was sufficient. (NOTE: make sure you have a very recent version of Perl installed. My Redhat 5.2 needed to be upgraded to m4 before the examples would work. Also, get the errata from O'Reilly.) The early chapters deal with basic constructs and widgets, and spend a great deal of time on the geometry managers (go figure). Each chapter introduces a new widget, although some are used before they are introduced (just nod and smile when you see those and don't worry). There are plenty of examples, code fragments, and exercises to keep anyone busy. I tried to work as many as I could, to get a feel for the language, and generally felt like they were helpful. I never felt completely lost or confused, and generally followed things without much trouble. Having finished the book, I feel confident that, given a little work on my Perl, I could write a useful application with Tk, especially given some research on CPAN for various contributed modules. For me, the book worked.

What's Bad?

Nothing in this book is particularly bad, although there are a few nits I'd like to pick. First, the early emphasis on geometry was somewhat interesting. I'm not sure why I care about grid vs pack when I can barely create a button to put on the screen. For that matter, frames are referenced in a short chapter late in the book, after being used all throughout. If the concept is so basic, why not put it toward the beginning? Also, there were times when the author mentions that an option is esoteric, or generally unused, and then spends much more time than necessary on that point. If it's so esoteric, why is it being covered in a basic book like this one? Finally, there were a few times that the book did not explain a point well enough to me, and I had to divine the answer down the road (like configuring scrollbars). It was not a major issue, but there were some things that could have been clearer.

What's In It For Us?

If you want to learn Tk using Perl, this book will let you do that. It gives a solid introduction to the topic, and on completion, you will be a useful Perl/Tk programmer. Just know your Perl going in, and you will be fine.

Purchase the book over at Computer Literacy.

1. Preface
   
2. Introduction to Perl/Tk
3. Geometry Management
4. The Basic Button
5. Checkbuttons and Radiobuttons
6. Label and Entry Widgets
7. Scrollbars
8. The Listbox Widget
9. The Text Widget
10. The Canvas Widget
11. The Scale Widget
12. Menus
13. Frames
14. Toplevel Widgets
15. Binding Events
16. Composite Widgets
17. Methods for Any Widget

1. Configuring Widgets with configure and cget
2. Operating System Differences
3. Fonts
   Index

bjb writes "The Wall Street Journal reported this morning that Sun plans to announce later today that they are going to distribute designs of their microprocessors to outside developers for free. Similar to the Java license that recently came out, you can modify it, but if you sell you have to pay. The schedule appears that they will release the PicoJava first, the 32-bit SPARC technology by the summer, and the 64-bit UltraSPARC technology by the end of the year." This article requires a paid login to read- what a crock. Anyway, someone please submit a free link. Update: 03/02 12:09 by S : News.com is now carrying the story. It's interesting to see how this move fits into Forbes' analysis Sun's strategy of getting attention with buzz around Java, Jini, and now Sparc Processors, in order to attack the very high-end more effectively. In the world of Starfire and Serengeti (supercomputers), Sun is probably telling the truth when they say that Linux does not compete with them (long term).

After a long hiatus away, Jason Bennett has returned to book reviewers with this review of Gerald M. Weinberg's The Psychology of Computer Programming (Silver Anniversary Edition). This book talks about the meta side of CS, and this book is where many of the other mental CS books have their roots-which means some repitition. Click below for more info. The Psychology of Computer Programming (Silver Anniversary Edition) author Gerald M. Weinberg pages publisher Dorset House rating 7/10 reviewer Jason Bennett ISBN 0-932633-42-0 summary

In many ways, this is the book that started the "meta" trend in computer science. Most books that discuss the mental side of CS have their roots here. Unfortunately, that also means that you've heard it all before.

Background

Long time, no talk! Unfortunately, my reading schedule didn't exactly go as planned (for various and sundry reasons, like slackness), and thus my reviews have not been coming as fast and furious as before. It's good to be back in the saddle again, however, dispensing syrup and vitriol as required.

What's the book about?

The original preface to POCP says it best: "to trigger the beginning of a new field of study: computer programming as a human activity...." Before the original edition, most books viewed programming in a mechanical fashion, in terms of how better to turn a crank. Weinberg, however, deliberately took a different approach: programming is done by people, as part of a thought process, and should be studied as any other thought process. This book focuses on the people aspects of programming, and how people think about doing programming. It discusses how to study programming, how people work together on programming projects, how people program alone, and what tools people use to get their work done. In short, it discusses how people program, not how code is best churned out.

What's Good?

Even though this is the original book on programming psychology, Weinberg managed to hit most of the important facets of the subject. Now, 25 years and many books later, he has come back to the subject. The book itself consists of all of the original work, annotated with chapter-ending notes and reflections. In other words, you read the original chapter, and then Weinberg's thoughts on it. This is not unlike the anniversary edition of Mythical Man-Month, although there is much less new material here. As with most meta-books, the ideas have aged well. People don't change much over 25 years, even though their surroundings do. Egoless programming, the passing around of code for peer analysis, was pioneered in the original work, proven over the years, and still needs to be implemented in more ways. Generally, Weinberg introduces the entire field of computer psychology, laying the groundwork for an entire area of research.

What's Bad?

Well, to be perfectly honest, I didn't enjoy the book that much, at least in terms of enjoying the reading. I feel that I learned some things, but I don't think the book has aged well in certain areas, and additionally I felt that much of the material was covered elsewhere. MMM taught me things that I had never thought of before, and in fact have not been well covered elsewhere since then. Plus, there was a huge section analyzing the entire book. TPOCP, on the other hand, has pages and pages devoted to annoying PL/I details, while adding only a few blurbs here and there. Note that the ideas themselves are still important, there's just a lot to wade through to get to them. In addition, I think this material has been well covered by books such as Peopleware and others. The book is enough of a classic that nothing can be said to be "bad," but I question if it hasn't been superceded.

What's In It For Us?

It's always important to look at we do on a metaphysical level. Computer science and software engineering are some of the most non-physical work areas known, and because of that can be difficult to analyze. Whether you choose this book, or one of the others mentioned above, do read up on how people deal with programming. It's just as important, if not more so, than language syntax or new IDE's.

Purchase the book over at Computer Literacy.

Preface to the Silver Anniversary Edition
Original Preface
Comments on the Original Preface
Suggestions for Course Use

Part 1: Programming as Human Performance

1. Reading Programs
2. What Makes a Good Program?
3. How Can We Study Programming?
   
   Part 2: Programming as a Social Activity
4. The Programming Group
5. The Programming Team
6. The Programming Project
   
   Part 3: Programming as an Individual Activity
7. Variations in the Programming Task
8. Personality Factors
9. Intelligence, or Problem-Solving Ability
10. Motivation, Training, and Experience
    
    Part 4: Programming Tools
11. Programming Languages
12. Some Principles for Programming Language Design
13. Other Programming Tools
    
    Part 5: Epilogue
    Index

After a long hiatus away, Jason Bennett has returned to book reviewers with this review of Gerald M. Weinberg's The Psychology of Computer Programming (Silver Anniversary Edition). This book talks about the meta side of CS, and this book is where many of the other mental CS books have their roots-which means some repitition. Click below for more info. The Psychology of Computer Programming (Silver Anniversary Edition) author Gerald M. Weinberg pages publisher Dorset House rating 7/10 reviewer Jason Bennett ISBN 0-932633-42-0 summary

In many ways, this is the book that started the "meta" trend in computer science. Most books that discuss the mental side of CS have their roots here. Unfortunately, that also means that you've heard it all before.

Background

Long time, no talk! Unfortunately, my reading schedule didn't exactly go as planned (for various and sundry reasons, like slackness), and thus my reviews have not been coming as fast and furious as before. It's good to be back in the saddle again, however, dispensing syrup and vitriol as required.

What's the book about?

The original preface to POCP says it best: "to trigger the beginning of a new field of study: computer programming as a human activity...." Before the original edition, most books viewed programming in a mechanical fashion, in terms of how better to turn a crank. Weinberg, however, deliberately took a different approach: programming is done by people, as part of a thought process, and should be studied as any other thought process. This book focuses on the people aspects of programming, and how people think about doing programming. It discusses how to study programming, how people work together on programming projects, how people program alone, and what tools people use to get their work done. In short, it discusses how people program, not how code is best churned out.

What's Good?

Even though this is the original book on programming psychology, Weinberg managed to hit most of the important facets of the subject. Now, 25 years and many books later, he has come back to the subject. The book itself consists of all of the original work, annotated with chapter-ending notes and reflections. In other words, you read the original chapter, and then Weinberg's thoughts on it. This is not unlike the anniversary edition of Mythical Man-Month, although there is much less new material here. As with most meta-books, the ideas have aged well. People don't change much over 25 years, even though their surroundings do. Egoless programming, the passing around of code for peer analysis, was pioneered in the original work, proven over the years, and still needs to be implemented in more ways. Generally, Weinberg introduces the entire field of computer psychology, laying the groundwork for an entire area of research.

What's Bad?

Well, to be perfectly honest, I didn't enjoy the book that much, at least in terms of enjoying the reading. I feel that I learned some things, but I don't think the book has aged well in certain areas, and additionally I felt that much of the material was covered elsewhere. MMM taught me things that I had never thought of before, and in fact have not been well covered elsewhere since then. Plus, there was a huge section analyzing the entire book. TPOCP, on the other hand, has pages and pages devoted to annoying PL/I details, while adding only a few blurbs here and there. Note that the ideas themselves are still important, there's just a lot to wade through to get to them. In addition, I think this material has been well covered by books such as Peopleware and others. The book is enough of a classic that nothing can be said to be "bad," but I question if it hasn't been superceded.

What's In It For Us?

It's always important to look at we do on a metaphysical level. Computer science and software engineering are some of the most non-physical work areas known, and because of that can be difficult to analyze. Whether you choose this book, or one of the others mentioned above, do read up on how people deal with programming. It's just as important, if not more so, than language syntax or new IDE's.

Purchase the book over at Computer Literacy.

Preface to the Silver Anniversary Edition
Original Preface
Comments on the Original Preface
Suggestions for Course Use

Part 1: Programming as Human Performance

1. Reading Programs
2. What Makes a Good Program?
3. How Can We Study Programming?
   
   Part 2: Programming as a Social Activity
4. The Programming Group
5. The Programming Team
6. The Programming Project
   
   Part 3: Programming as an Individual Activity
7. Variations in the Programming Task
8. Personality Factors
9. Intelligence, or Problem-Solving Ability
10. Motivation, Training, and Experience
    
    Part 4: Programming Tools
11. Programming Languages
12. Some Principles for Programming Language Design
13. Other Programming Tools
    
    Part 5: Epilogue
    Index

Maniacal wrote in to let us know about an article that talks about new "service" Yahoo! has implemented that would move e-commerce sites to the top of the line for placement, for 199$. As almost everyone knows, Yahoo! doesn't use spiders, but humans for placement. This means that the placement of a particular site can take a /long/ time. This service would move the sites using it to the front of the line-although Yahoo! still doesn't guarantee placement, nor will it necessarily guarantee priority placement. This service is part of new wave of services that Yahoo! will be aiming at small business. While part of me thinks this is the wrong way to do it, I know that a lot of places out there will use it-but for the true small scale start-ups, this still hurts.

Daniel Roberts wants to know about the following:: "I am running Red Hat 5.2, and I have been trying to upgrade to 2.2 since pre1. My problem is, I have read through the "Changes" file very carefully, and tried to upgrade all the needed packages... But it still won't work. I am looking for binary RPMs whenever I can, but even Raw Hide does not seem to have all the needed updates to make it work. In particular, I cannot get libc5.4.46 to work, for some reason, even though I've tried to install the binary tar version. My question is: what do I need to do to get Linux 2.2.0 working properly with a stock Red Hat 5.2 system??" Update: 02/12 03:02 by C : I've just discoveded information about "Project Tango" which may be the answer to this question. Thanks to Palin for the heads up. C :I was going to run this as another story on this, but after rereading I figure it's better if we add in this libc-5 issue from davie, who is in the process of a similar upgrade:

"I've built and installed libc-6 and it seems to be working fine. Now I need (at least according to the Changes text in the kernel source) to upgrade my libc-5. The problem is, I can't find any references on how to install a new build of libc-5 for compatability support only--I'm concerned that if I just 'configure, make, make install', I will break libc-6. I've looked at every FAQ and HOWTO I can find and there's nothing helpful. I looked at a libc-5 update RPM for RH 5.1, but I'm reluctant to guess where files go and which files need to be replaced. The libc-5 binary tarball includes fewer files than the update RPM, so I'm not sure what to do. Is there a doc online that explains how to build libc-5 and install it for compatability on a libc-6 box?"

Palin wrote in with this information...and a reliability question on the Tango Project, which looks to be the cure for this problem:

"Do you or anyone else in the Linux comunity know if the Tango Project's RPMs work? If you don't know what the Tango project is... It is a set of rpms for Redhat Linux 5.2 that provide all the necessary software (in RPM format) that one needs to install a 2.2.X kernel. I'd like to apply them...but was wondering what success others have had... The software can be found.... here and here. If it works I might be able to mirror it in the US...but I'm not going to try unless I know people have had success with it... "

Sara Killingsworth wrote in with a press release from Be saying that they have selected Cygnus's GNUPro to be the compiler on their OS. I've attached the full press release below if you're curious. It mentions that Cygnus's compiler solution perfored 20% faster.

FOR IMMEDIATE RELEASE Contacts: Becky Wood DiSorbo (408) 542-9667 bwood@cygnus.com Sara Killingsworth

(602) 961-1515 saralk@home.com

CYGNUS GNUPRO TOOLS POWER BE OPERATING SYSTEM

Cygnus Solutions Delivers Software Development Tools that Increase Stability and Performance of Be, Inc.'s Media Operating Systems

SUNNYVALE, Calif., January 19, 1999 - Cygnus( Solutions today announced that Be(, Inc. selected Cygnus GNUPro software development tools for the recently shipped Release 4 of the Be Operating System (BeOS*). GNUPro(, the leading compiler and debugger toolchain for native and embedded development, provides BeOS developers with the software development power to work at maximum efficiency, and an open-source code base for greatest flexibility during the design cycle. According to recent tests conducted by Be, GNUPro tools performed 20 percent faster than other software development tools. More detailed information can be found at link "An operating system is nothing without good development tools. Giving our developers the best possible tools to work with helps them to create the fastest, most groundbreaking applications," said Scott Paterson, director of Marketing at Be. "As a leader in open-source software development technologies, Cygnus GNUPro enables Be developers to benefit from improved performance and a broader tool chain, which results in rapid innovation and high quality software." GNUPro provides a single-source toolchain for easy portability and maximum code reuse, and supports more than 125 host-target cross-development environments, covering the vast majority of the most popular host-target platforms. "Providing Be with Cygnus' GNUPro tools is further evidence of the increasing platform success of GNUPro and of open source technologies," said Scott Petry, vice president of marketing at Cygnus. "Cygnus ensures that open standard software development technologies, including GNUPro, are the most powerful resources available for commercial development."

About GNUPro
GNUPro includes ANSI-conforming C/C++ compilers, a macro-assembler, the Cygnus Insight( visual debugger, binary utilities, libraries, and broad support for Windows NT/95 and UNIX hosted toolkits. Users benefit from Cygnus' premier software engineering, availability of tools for a wide range of processors, stringent testing (more than five million controlled and documented tests against each host-target combination) and custom enhancements. Cygnus delivers GNUPro through an innovative subscription model that includes regular software upgrades, featuring the latest innovations in GNU technology, as well as mission-critical support services for rapid response and resolution of technical questions or problems. Pricing for a five-user team starts at $7,495 and includes a one-year subscription. For more information on GNUPro pricing and the more than 125 host-target cross-development environments supported by Cygnus GNUPro, contact Cygnus corporate headquarters in Sunnyvale, Calif. at 1-408-542-9600, 1-800-CYGNUS-1, info@cygnus.com, or visit the Web site at link

About Be
Be, Inc., founded in 1990 by Jean-Louis Gassée, is a software company focusing on building new foundations for the next generation of digital content and media design tools. With a team of industry-leading engineers and business executives in the United States and Europe, the company is dedicated to removing the limitations of existing computer architectures and delivering a new level of price performance. In December 1998, Be published Release 4 of the Be Operating System (BeOS), the core product of this strategy. Additional information on Be and the BeOS is available online at link Be, Inc. is headquartered in Menlo Park, California.

About Cygnus Solutions
The market leader in software development technologies for computing applications, Cygnus( Solutions offers build-time and run-time solutions based on an open-source model. From GNUPro( Toolkit to eCos(, the Embedded Cygnus Operating System, Cygnus' open-source and royalty-free software benefits system developers in a wide variety of market segments, including consumer electronics, Internet, telecommunications, office automation, networking, aerospace and automotive. Cygnus' products, custom engineering services, and world-class support services enable developers to bring products to market faster at reduced system development costs. Founded in 1989, with headquarters in Sunnyvale, California, Cygnus has sales and engineering offices throughout North America, Japan, and the United Kingdom.

Cygnus GNUPro Powers BeOS Page 2

*Cygnus and GNUPro are registered trademarks, and Sourceware and eCos are trademarks of Cygnus Solutions. Open Source is a Certification Mark of the Open Source Initiative. All other company and product names are trademarks of their respective owners. "

bjb writes "According to Entertainment Weekly, TNT will be broadcasting in May a show called "Pirates of Silicon Valley", which will follow Steve Jobs (Noah "ER" Wyle) and Bill Gates (Anthony Michael "Wierd Science" Hall). Supposedly this should be "accessible even to the non-computer savvy" " In other words, it probably won't be interesting to us. But I'm curious- We should SlashNET simulcast it and MST it into another dimension. Anyway, that link requires a paid login, but I've seen this elsewhere too so it's definitely true. Someone post some free links if you find 'em.

Darren Morofke wrote to ask the Canadians in our audience to head over and sign a petition against the proposed CD-R tax. We had covered this tax when it was first coming around-let's see if we can help put a stop to this.

I tell ya, the end of the year is when all the cheesy awards things come out of the woodwork. First off, you can still vote for Slashdot as Cool Site of the Year. First prize is a new guitar (mmmm). Next Newswire has named Slashdot as winner of the "Community" section of it's Big 14 roundup. tapwater wrote in to say that The Guardian ranked us as one of the Top 10 Sites of 98. Modbuster wrote in to tell us that PlanetClick.com gave us 'Coolest Site'. Finally Norman Jordan says that @Home Network gave Slashdot a five star rating and ranked it as the best site overall for 1998.

I tell ya, the end of the year is when all the cheesy awards things come out of the woodwork. First off, you can still vote for Slashdot as Cool Site of the Year. First prize is a new guitar (mmmm). Next Newswire has named Slashdot as winner of the "Community" section of it's Big 14 roundup. tapwater wrote in to say that The Guardian ranked us as one of the Top 10 Sites of 98. Modbuster wrote in to tell us that PlanetClick.com gave us 'Coolest Site'. Finally Norman Jordan says that @Home Network gave Slashdot a five star rating and ranked it as the best site overall for 1998.

When I put out my call for Geek Christmas Gift ideas, I had no idea what I was in for. But after the storm of email that followed was washed away, I was left with a list of toys that any geek would be excited to give or get this year for whatever holiday it is you celebrate this time of year. Hit the link below and read the list if you're curious. Random Stuff There were a few things that were suggested, that, well, I bet Santa won't come through for them. Hemos asks for Nanites. Thats all he wants. Nanites. Somebody smack him. Nima Negahban says "I would like the beowolf cluster avalon for christmas, dont worry about it fitting it under the tree. " david yates wrote in and simply said "Half naked Princess Leia ,as Jabba's prisoner, action figure." I'm sure his mother is proud. He can have the Action Figure, I want 1976 Carrie Fisher. Games Everyone and their brother wrote in to say that Nintendo 64's and Playstations are great. And the game of choice is definitely Zelda 64. I second that motion. I suggested it to my dad as a Christmas Present. Terrible idea- now I gotta wait until xmas to find out if he got it, and if he *didn't* I gotta buy in on Dec 26. Hard as hell to find. Folks suggested other things like the original Kings Quest or Leisure Suit Larry. Prince of Persia. Commander Keen. Ultima. All those games that aren't around any more, but with their original packaging. Finding a 5.25" drive to play them with might be a tad tricky tho. Clothing It's a well known fact that its better to be clothed at least part of the time. And no self respecting geek should be without a vast array of appropriately political t-shirts to pad out your closet full of suits, jackets, and ties (cough). Daniel suggested checking out the Free BSD Mall for BSD clothing. Jonathan Moore suggested the ever popular KMFMS t-shirts for your local microsoft hater. If thats a bit to exotic for you, how about the classic that Doug Boettcher sent us: the Hack Naked shirt. Since we're mentioning all these t-shirts, we ought to mention that CopyLeft has several shirts including my Don't Fear the Penguins ones, and Slashdot ones too. Software Several folks wrote in to say that they were buying Linux CDs from any of the various places that sell them, and giving them away to the needy. I tend towards Linux Central, and in addition to them Cheap Bytes OpenBsd.org and The Linux Mall were all suggested as places where you can buy the stuff we like. Hardware By far the largest catagory for gift ideas was of course Hardware:The Gift that Costs to much. Of course, anyone would want a a Palm III- it's hard to think of a better stocking stuffer. And besides, they're practically money in the bank now that you can use them to collect automobiles of the rich and famous. But if you've already got a Pilot, James A. Hillyerd suggests a GoType keyboard as the perfect accessory. If the pilot isn't your bag, but you want to read on the road, Mahlen Morris suggested A Rocket E-Book which is basically a tablet computer that is designed to replace books You can get them here. And apparently they have some sort of deal with Barnes & Nobles so you can get content to read on it. They're pretty sweet looking- someday we'll have a wireless version with net access, then we can forget paper. But for now, this'll do.

Have trouble remembering passwords? Digital Persona sells sweet hardware that that you can use to do finger print identification. Suggested by Andrew Lepisto. The pdQ was suggested by Adam D. McKenna. Its a cel phone with an integrated Pilot. Another fairly common suggestion for geek gifts was cel service from your local provider, and a cel modem for the laptop equipped gift getter. Sean McPherson suggested a Kodak DC210+ digital camera. Saves big bucks on film, and is supposed to be supported by SANE. I'm actually planning on getting a Digital Camera before the upcoming string of conferences, and I'll probably look at this one (unless Santa already has one in his bag for me, although at $400 a pop, I highly doubt it) Steven McDonald suggests that we look at DVD RAM Drives as a new huge backup device for storing your MP3s and Porn. Oh, and legit data too.

Mike Miller sent us several suggestions including the Happy Hacking Keyboard. I played with one at ALS- they're not bad. Just as cool are the new Color Gamesboys. I suppose tetris wouldn't be vastly improved by color, but its still pretty sweet. For those with a hugeass budget, How about your very own Alpha Cluster? Obviously Jakob is a lot more hopeful for Saint Nick than I am this year *grin*. How about a vt320 Terminal? Daniel Morrison suggested it, and I think it sounds pretty cool. I had a terminal attached to one of my Linux boxes for awhile. I Let it tail log files and stuff. Kinda fun for reading documentation and stuff too. Can't afford a Multi-Head X-Server, video card, and spare monitor anyway. Plus you can run them into another room and check your email from your kitchen/dining room/bathroom.

Matthew J. Allen sent us a pricey one, but its oh so sweet: Remember those Huge Flat LCD Screens from SGI? I sure do. I wake up after erotic dreams about them. (SUBLIMINAL MESSAGE:Hey SGI: Give Rob one of those things for banner ads. You've got a spare one just sitting around, right?). Matthew also suggested an Iomega Clik Drive if you're on a more reasonable budget. Those things do look pretty sweet. Do cables piss you off? How about the gift of a tangle free workspace? Scott Donovan sent us a link to Cordless Mice and Keyboards from Logitech that will free you up for spinning on your swivel chair really fast until you fall over from getting dizzy instead of getting tangled up in your keyboard cable.

Toys By far the single most suggested toy of all was the Lego Mindstorms. The robotic legos are quite possibly the coolest toy in the history of toys. They aren't cheap, but they are oh so sweet. Else you could consider X-Files Action Figures suggested by E. Waugh. Home Entertainment and Audio Gear The Panasonic Portable DVD Theater was sent in by Joel Telling. Its a tiny portable DVD player obviously designed to make me froth at the mouth like a rabid dog. Several folks wrote in to suggest something I would like, but I wouldn't want to froth on. The Empeg Car CD Player. We've mentioned this before, and although they won't be ready for christmas, they are pretty amazing. 2.1 gigs of MP3s in a car stereo. They need a 9 gig version mounted in a home stereo component too.

Jon Jones (is that a real name? *grin*) wrote in to send a link to ADB I/O which you can use to automate your home for the ultimate in comfort and/or laziness. For the true audio junkie, how about the THX Speakers sent in by Chad R. Henry. Sure, they cost more than my car, but I bet they sound amazing. If you're on a more modest budget Cambridge SoundWorks has some slightly more reasonably priced speakers that I'm told sound awesome. Andrew Hobgood suggests checking out Panasonic SJ-MJ70 MiniDisc Player (portable). Pretty sweet if you aren't willing to chance it on the Diamond Rio (which was also one of the most common suggestions). Frankly any geek should be excited to get either. Rob Sheehy pointed out that Philips has 42 inch widescreen flat TVs that you could hang on your wall if you happen to be rich and wanna watch letterbox movies. This one has a VGA input too.

Random Terry A. Braun suggests that geeks need to get into making our own beer. Sounds like a great idea to me, although I tend to screw up toast. But if you're man enough to try it, you can get Your Own Grain Mill. Alan Mathews wrote in to suggest a A dilbert M&M dispensor McPhee's has some strange stuff, including a Punching Nun suggested by Glen Lipka Tom Berger suggested A VI Command Set Mug STriker RedWolf sent us a link to a chocolate bar shaped like a Pentuim II Chip.

Jason Grundy suggests the $6 card game Kill Dr. Lucky and a Card both from the aptly titled Cheapass.com. Rob Pelkey sent in a pair of gift ideas that are a world apart. The first is An Authentic Moon Rock and the second is a Jesse Ventura T-Shirt or Bumper Sticker. One is probably worth a little more than the other. The concept kitchen has this wierd Finger Stylus Thingee that you can use instead of a pen for some pen machines. Kinda wacky. Sent to us by Wyatt Earp.

Justin Higgins suggests that geeks should all own a copy of the Star Wars Radio Drama. Sure, it costs almost a hundred bucks, but at 15 CDs, it balances out to almost be a bargain. They ought to package it on 1 CD full of MP3s, throw a copy of the script on the disc and sell it for $20. I'd never heard of the Leatherman Wave before, but several folks emailed me to say they are cool. And then I noticed that they were actually advertising here. Shows how much attention I pay to who advertises on my own site I guess. But still several people raved about them, claiming that they're ideal for mucking around inside computer cases with. And Traci Earl sent a link to a site that makes nice Leather Cases for them.

Do you think stuffed animals are stupid? Well how about a Stuffed Plush Space Shuttle? Dave Brunberg sent us that gem. Stirling Westrup sent in a link to something called the Hoberman Sphere which basically is a crazily designed sphere thingee that expands from 9.5" to 30". Crazy looking. If you're looking for something caffienated that you can put in your mouth, several folks reminded us about caffienated penguin mints.

Wrap Up Well this was fun guys. Spending hours looking at crazy things that I can't afford has convinced me to take up cracking banks as an evening hobby. But what is quite obvious is that 1998 is a good year to be a geek. And maybe in 1999 Hemos can have his nanites. Nah.

And lastly, with all the commercial hub bub that tends to go on during this season, don't forget the true meaning of Christmas: Ham.

Starting the week off in our customary fashion Jason Bennett sent in his latest book review. This time around, we're looking at The Deadline, written by Tom DeMarco. This book takes on a might-as-well-be-true story about some of the problems with software development management. Click below to read more. The Deadline author Tom DeMarco pages publisher Dorset House rating 9/10 reviewer Jason Bennett ISBN 0-932633-39-0 summary DeMarco has extended his writing from Peopleware in an interesting form: allegorical novel. Tom Clancy isn't shaking in his boots, but as a pedagogical tool, the fiction works quite well. Some excellent points are made regarding project management and dealing with evil managers. Background

Greetings once again, all. This week we're taking a trek back toward project work with DeMarco's latest work. The allegory has been done before elsewhere (I personally enjoyed Alice in Quantumland ), but I don't believe it's been used in this realm before. I've got another book or two under my belt before I'll need to pause for a reload. For now, though, The Deadline....

What's the book about?

Technically, it's a fictional story about Webster Tompkins, a "downsized" project manager from BT&T (yeah, figure that out). He's hired to work in Moravia for NNL (the Nation's Noble Leader) to turn the country into a software powerhouse. DeMarco then concocts a scenario where Tompkins endures most of the typical problems of a software project manager. He has quite a nice brain trust working with him to help him along and bring out new solutions. The kicker is, since most every software engineer in the country is involved, they have tons more people than they need. Thus, they set up multiple teams for each product in a software engineering laboratory, to test out different ideas. Sprinkled throughout are bad bosses, bad subordinates, staffing issues, metrics, interesting new techniques, various complications, and plenty of DeMarco's own ideas.

What's Good?

The conceit is an interesting idea, and the narrative tends to flow well. There are plenty of scenarios included in the book, and lots of new ideas that you likely haven't tried are mentioned as well. Also, DeMarco summarizes the points he's made in each chapter with a "journal entry" of Mr. Tompkins, in case the reader misses the point of the story. The references to various famous people are also nice, if only because DeMarco tends to summarize what that person believes about a certain issue (yes, even our favorite nemesis makes an appearance). Overall, the story flows quite well, and if you are a project manager, or are on a project team, you can learn from this book. In general, remember the essentials of good management: "get the right people, match them to the right jobs, keep them motivated, and help the team jell and stay that way. Everything else is administrivia."

What's Bad?

Unfortunately, at times the conceit breaks down. DeMarco isn't exactly a great fiction writer (the romantic parts aren't well staged), although admittedly that isn't the point of the book. Also, at times the book's plot is somewhat staged in order to accommodate all of the lessons that DeMarco wants to put in. I also happen to disagree with a few points that DeMarco makes (especially as relates to CMM), but he always has a point, at the very least.

What's In It For Us?

This book is an excellent companion to two previous books that I've reviewed, DeMarco's Peopleware and McConnell's Software Project Survival Guide This book takes a somewhat different tact, of course, and end sup synthesizing the two books. While McConnell deals with process, and Peopleware deals more with employees, Deadline deals with the people issues from the manager's standpoint. Anyone who manages (or participates in!) a software project, whether commercial or open source, will run into the problems detailed in The Deadline. It's always better to be prepared beforehand!

Purchase the book over at Amazon.

1. Preface
2. Opportunity Knocking
3. Standing Up to Kalbfuss
4. Silikon Valejit
5. The CD-ROM Plant
6. NNL
7. The World's Greatest Project Manager
8. Taking On Staff
9. The Eminent Dr. Rizzoli
10. Ex-General Markov
11. Abdul Jamid
12. The Sinister Minster Belok
13. The Numbers Man
14. QuickerStill
15. Moravia's First Programmer
16. Think Fast!
17. Planning for the Summer Games
18. The Guru of Conflict Resolution
19. Maestro Diyeniar
    Interlude
20. Part and Whole
21. Standing on Ceremony
22. Endgame Begins
23. The Year's Hottest IPO
24. Passing Through Riga on the Way Home

Starting the week off in our customary fashion Jason Bennett sent in his latest book review. This time around, we're looking at The Deadline, written by Tom DeMarco. This book takes on a might-as-well-be-true story about some of the problems with software development management. Click below to read more. The Deadline author Tom DeMarco pages publisher Dorset House rating 9/10 reviewer Jason Bennett ISBN 0-932633-39-0 summary DeMarco has extended his writing from Peopleware in an interesting form: allegorical novel. Tom Clancy isn't shaking in his boots, but as a pedagogical tool, the fiction works quite well. Some excellent points are made regarding project management and dealing with evil managers. Background

Greetings once again, all. This week we're taking a trek back toward project work with DeMarco's latest work. The allegory has been done before elsewhere (I personally enjoyed Alice in Quantumland ), but I don't believe it's been used in this realm before. I've got another book or two under my belt before I'll need to pause for a reload. For now, though, The Deadline....

What's the book about?

Technically, it's a fictional story about Webster Tompkins, a "downsized" project manager from BT&T (yeah, figure that out). He's hired to work in Moravia for NNL (the Nation's Noble Leader) to turn the country into a software powerhouse. DeMarco then concocts a scenario where Tompkins endures most of the typical problems of a software project manager. He has quite a nice brain trust working with him to help him along and bring out new solutions. The kicker is, since most every software engineer in the country is involved, they have tons more people than they need. Thus, they set up multiple teams for each product in a software engineering laboratory, to test out different ideas. Sprinkled throughout are bad bosses, bad subordinates, staffing issues, metrics, interesting new techniques, various complications, and plenty of DeMarco's own ideas.

What's Good?

The conceit is an interesting idea, and the narrative tends to flow well. There are plenty of scenarios included in the book, and lots of new ideas that you likely haven't tried are mentioned as well. Also, DeMarco summarizes the points he's made in each chapter with a "journal entry" of Mr. Tompkins, in case the reader misses the point of the story. The references to various famous people are also nice, if only because DeMarco tends to summarize what that person believes about a certain issue (yes, even our favorite nemesis makes an appearance). Overall, the story flows quite well, and if you are a project manager, or are on a project team, you can learn from this book. In general, remember the essentials of good management: "get the right people, match them to the right jobs, keep them motivated, and help the team jell and stay that way. Everything else is administrivia."

What's Bad?

Unfortunately, at times the conceit breaks down. DeMarco isn't exactly a great fiction writer (the romantic parts aren't well staged), although admittedly that isn't the point of the book. Also, at times the book's plot is somewhat staged in order to accommodate all of the lessons that DeMarco wants to put in. I also happen to disagree with a few points that DeMarco makes (especially as relates to CMM), but he always has a point, at the very least.

What's In It For Us?

This book is an excellent companion to two previous books that I've reviewed, DeMarco's Peopleware and McConnell's Software Project Survival Guide This book takes a somewhat different tact, of course, and end sup synthesizing the two books. While McConnell deals with process, and Peopleware deals more with employees, Deadline deals with the people issues from the manager's standpoint. Anyone who manages (or participates in!) a software project, whether commercial or open source, will run into the problems detailed in The Deadline. It's always better to be prepared beforehand!

Purchase the book over at Amazon.

1. Preface
2. Opportunity Knocking
3. Standing Up to Kalbfuss
4. Silikon Valejit
5. The CD-ROM Plant
6. NNL
7. The World's Greatest Project Manager
8. Taking On Staff
9. The Eminent Dr. Rizzoli
10. Ex-General Markov
11. Abdul Jamid
12. The Sinister Minster Belok
13. The Numbers Man
14. QuickerStill
15. Moravia's First Programmer
16. Think Fast!
17. Planning for the Summer Games
18. The Guru of Conflict Resolution
19. Maestro Diyeniar
    Interlude
20. Part and Whole
21. Standing on Ceremony
22. Endgame Begins
23. The Year's Hottest IPO
24. Passing Through Riga on the Way Home

Perenial contributor Jason Bennett has sent in a review of Built to Last, by James C. Collins and Jerry I. Porras. This is part of Jason's continuing series of review about books that are not directly code related, but about how you run a programming/information shop. Check out the full review below. Built to Last author James C. Collins and Jerry I. Porras pages publisher HarperBusiness rating 9/10 reviewer Jason Bennett ISBN 0-88730-739-6 summary This is the first book I've ever read the confirmed what I've always believed: that the best companies are the ones that put people above profits. Background

Welp, it's been a couple of weeks of slackfest over here, but I finally got my butt in gear. Unfortunately, I had to loan out the book I was going to review at the last minute, so I thought I'd substitute this one. I also just finished The Deadline by Tom DeMarco, and have had a nice email conversation with him. Great book, with a neat story and lots of excellent points. I'll get to it in a few weeks. For now, a book that relates to computers the least of all the ones I've done, yet I think gets to the heart of something that the Linux community embodies: that our beliefs are more important than going along with the group. Check it out!

What's the book about?

Built to Last is the collected knowledge of a study that began in 1989 to discover what makes visionary companies. Visionary companies are "premier institutions -- the crown jewels -- in their industries, widely admired by their peer and having a long track record [at least 50 years in this study] of making a significant impact on the world around them." This was done by surveying CEOs and finding out which companies they admired, then studying them in comparison to similarly long-lived companies that were not as admired or successful. The visionary companies are the truly special ones, while the comparison companies are just good enough. But what makes a company visionary? In short, the visionary companies are not the ones with the great ideas of charismatic leaders, but the ones which build the company instead of building thing. Visionary companies are the ones which believe in something (anything!) above profits. Visionary companies are the ones which preserve a set of core beliefs which stimulating progress into the future. Visionary companies set BHAGs (Big Hairy Audacious Goals), goals which are almost impossible, and believe that those goals can be met. Visionary companies have a culture that is almost a religion, where the employees share a set of beliefs (the core values) and live them out every day. Visionary companies are not afraid to try new things, as long as those new things do not violate the core beliefs. Visionary companies grow their own management who preserve the beliefs, instead of bringing in random outsiders. Visionary companies always strive to be better, and are not complacent. Visionary companies are not perfect, and they do stumble, but they are much better equipped to pick themselves up than their regular counterparts.

In short, we are all part of a visionary company: the Linux community. We believe in the freedom of software. We believe in choice of operating system. We believe that no one person of company should dictate what the rest of us do. In order to achieve this, we should be willing to change anything. The kernel. The UI. Heck, we should we willing to change to another operating system entirely, because whether we run Linux or FreeBSD is irrelevant. What is important is the fulfillment of our beliefs. Linus has sent a BHAG for us: World Domination. As long as we continue to build the community, and not just focus on the current OS, the Free Software movement will continue to be strong.

What's Good?

Ok, that was some good preaching. As I said, this book does not mention computer programming at all (save for having IBM as a visionary company), but it does describe us. This book details what is important: not money, but ideology. Money will flow from a strong ideology, but not the other way around. Those who take this book to heart will be part of a community, a company, that will flourish well into the next century.

What's Bad?

Heh, have I built this up enough? Seriously, though, the book isn't perfect. The structure can be a little haphazard at times, and there isn't a good listing of what the books conclusions are (they're a little scattered). The paperback does add a nice summary chapter that appeared in the Harvard Business Review, which covers this problem somewhat.

What's In It For Us?

I think I covered this. :-) Seriously, I think the Linux community would be well served to develop a set of core beliefs and core purposes and write them down. In this way, we could have an artifact of what we hold dear, a credo, that we can show to those who will be flocking to our gates. Obviously, not everyone who runs Linux (or a free OS) must hold these beliefs, just as not every IBM customer holds to their beliefs. Those who are "employees," however, should be thoroughly indoctrinated.

Purchase the book over at Amazon.

• Acknowledgements
• Introduction to the Paperback Edition
• Preface

1. The Best of the Best
2. Clock Building, Not Time Telling
3. No "Tyranny of the OR"
4. More Than Profits
5. Preserve the Core/Stimulate Progress
6. Big Hairy Audacious Goals
7. Cult-Like Cultures
8. Try a Lot of Stuff and Keep What Works
9. Home-Grown Management
10. Good Enough Never Is
11. The End of the Beginning
12. Building the Vision

• Epilogue: Frequently Asked Questions
• Appendix 1: Research Issues
• Appendix 2: Founding Roots of Visionary Companies and Comparison Companies
• Appendix 3: Tables
• Appendix 4: Chapter Notes
• Index

Perenial contributor Jason Bennett has sent in a review of Built to Last, by James C. Collins and Jerry I. Porras. This is part of Jason's continuing series of review about books that are not directly code related, but about how you run a programming/information shop. Check out the full review below. Built to Last author James C. Collins and Jerry I. Porras pages publisher HarperBusiness rating 9/10 reviewer Jason Bennett ISBN 0-88730-739-6 summary This is the first book I've ever read the confirmed what I've always believed: that the best companies are the ones that put people above profits. Background

Welp, it's been a couple of weeks of slackfest over here, but I finally got my butt in gear. Unfortunately, I had to loan out the book I was going to review at the last minute, so I thought I'd substitute this one. I also just finished The Deadline by Tom DeMarco, and have had a nice email conversation with him. Great book, with a neat story and lots of excellent points. I'll get to it in a few weeks. For now, a book that relates to computers the least of all the ones I've done, yet I think gets to the heart of something that the Linux community embodies: that our beliefs are more important than going along with the group. Check it out!

What's the book about?

Built to Last is the collected knowledge of a study that began in 1989 to discover what makes visionary companies. Visionary companies are "premier institutions -- the crown jewels -- in their industries, widely admired by their peer and having a long track record [at least 50 years in this study] of making a significant impact on the world around them." This was done by surveying CEOs and finding out which companies they admired, then studying them in comparison to similarly long-lived companies that were not as admired or successful. The visionary companies are the truly special ones, while the comparison companies are just good enough. But what makes a company visionary? In short, the visionary companies are not the ones with the great ideas of charismatic leaders, but the ones which build the company instead of building thing. Visionary companies are the ones which believe in something (anything!) above profits. Visionary companies are the ones which preserve a set of core beliefs which stimulating progress into the future. Visionary companies set BHAGs (Big Hairy Audacious Goals), goals which are almost impossible, and believe that those goals can be met. Visionary companies have a culture that is almost a religion, where the employees share a set of beliefs (the core values) and live them out every day. Visionary companies are not afraid to try new things, as long as those new things do not violate the core beliefs. Visionary companies grow their own management who preserve the beliefs, instead of bringing in random outsiders. Visionary companies always strive to be better, and are not complacent. Visionary companies are not perfect, and they do stumble, but they are much better equipped to pick themselves up than their regular counterparts.

In short, we are all part of a visionary company: the Linux community. We believe in the freedom of software. We believe in choice of operating system. We believe that no one person of company should dictate what the rest of us do. In order to achieve this, we should be willing to change anything. The kernel. The UI. Heck, we should we willing to change to another operating system entirely, because whether we run Linux or FreeBSD is irrelevant. What is important is the fulfillment of our beliefs. Linus has sent a BHAG for us: World Domination. As long as we continue to build the community, and not just focus on the current OS, the Free Software movement will continue to be strong.

What's Good?

Ok, that was some good preaching. As I said, this book does not mention computer programming at all (save for having IBM as a visionary company), but it does describe us. This book details what is important: not money, but ideology. Money will flow from a strong ideology, but not the other way around. Those who take this book to heart will be part of a community, a company, that will flourish well into the next century.

What's Bad?

Heh, have I built this up enough? Seriously, though, the book isn't perfect. The structure can be a little haphazard at times, and there isn't a good listing of what the books conclusions are (they're a little scattered). The paperback does add a nice summary chapter that appeared in the Harvard Business Review, which covers this problem somewhat.

What's In It For Us?

I think I covered this. :-) Seriously, I think the Linux community would be well served to develop a set of core beliefs and core purposes and write them down. In this way, we could have an artifact of what we hold dear, a credo, that we can show to those who will be flocking to our gates. Obviously, not everyone who runs Linux (or a free OS) must hold these beliefs, just as not every IBM customer holds to their beliefs. Those who are "employees," however, should be thoroughly indoctrinated.

Purchase the book over at Amazon.

• Acknowledgements
• Introduction to the Paperback Edition
• Preface

1. The Best of the Best
2. Clock Building, Not Time Telling
3. No "Tyranny of the OR"
4. More Than Profits
5. Preserve the Core/Stimulate Progress
6. Big Hairy Audacious Goals
7. Cult-Like Cultures
8. Try a Lot of Stuff and Keep What Works
9. Home-Grown Management
10. Good Enough Never Is
11. The End of the Beginning
12. Building the Vision

• Epilogue: Frequently Asked Questions
• Appendix 1: Research Issues
• Appendix 2: Founding Roots of Visionary Companies and Comparison Companies
• Appendix 3: Tables
• Appendix 4: Chapter Notes
• Index

Continuing his voyage, Jason Bennett has submitted his review of Peopleware. This is a book about how to run an office in the age of the "information worker". Not about coding, but about creating environments in which the work we are all used can be done. So, if you are interested (or have a manager who should read this), click below. Peopleware author Tom DeMarco and Timothy Lister pages publisher Dorset House rating 10/10 reviewer Jason Bennett ISBN 0-932633-05-6 summary An excellent book about how an office should be run. If you consider yourself an "intellect worker," read this book and apply its principles. Background

I apologize for the missed week. I was finishing up my report for work on this book, and didn't get around to my Slashdot review. I've also ended up changing the schedule, since this review was available, and Creating a Software Engineering Culture would have required duplicating a lot of work. Anyway, we'll get to it next week. I'm also currently reading Built to Last, an excellent book about what makes the difference between a decent company and a great ("visionary") company. I'm not sure that review belongs on Slashdot, but reader demand will help to influence that. :-)

What's the book about?

Peopleware is the collected knowledge of two long-time project managers. Specifically, they deal with what is wrong with how managers treat their people, and what is wrong with the work environment itself. The book talks in terms of software projects, but is useful to anyone who falls in to the category of "intellect worker"; in other words, those people who need to concentrate to work, as opposed to those who work in "interrupt mode."

Peopleware is organized into many separate, but related, essays. Once again, I'll be dealing with the book in chunks:

1. Managing the Human Resource (ch. 1-6)
2. The Office Environment (ch. 10-13)
3. The Right People (ch. 14-17)
4. Growing Productive Teams (ch. 18-23)
5. It's Supposed to Be Fun to Work Here (ch. 24-26)

"Managing the Human Resource" deals with how intellect workers should be treated. The main theme of the book is summed up on page 4: "The major problems of our work are not so much technological as sociological in nature." Ultimately, projects do not fail because people cannot understand the technology, but because the team itself breaks (or is broken). Workers must be treated as people, not as parts of a machine. So much of managerial theory assumes some sort of non-intellectual, "assembly line" development (be it a car plant or burger joint). Using these kinds of adversarial, non-thinking tactics will ruin an environment of people who are paid to think. Because those workers think, each one is unique and irreplaceable. You can't mine your "human resources" from the ground.

"The Office Environment" is one of the most focused, devastatingly effective parts I've read in a while. D&L systematically demolish the theory of cheap, open space, the notion that the environment does not effect people, and the notion that workspace is the place to save money. Consider that the cost of a worker's space is 1/20th of his salary over the average time he stays at one company (2 years). If a poor environment hampers that worker's productivity, the money saved in building that environment will be more than overshadowed by the extra time required for the worker to complete tasks. In fact, there are 11:1 differences in productivity between the best and worst organization. Should you be working 10 times more than you should?

The thesis behind "The Right People" is that it is critical to hire the best people in the first place, as a manager is not likely to mold a worker himself. Therefore, managers should strive to hire the people who will do the best job and complement the team the most, not the people who will most conform to some arbitrary standard. Allowing teammates to assist in the process, and keeping a long-term focus to reduce turnover, will help the situation.

"Growing Productive Teams" focuses on the concept of "jelled teams." These teams, where the members are highly focused on the goal, are much more productive than the individual members could ever be. These teams are difficult to make, but easy to destroy. Managers who give their people freedom and trust are most likely to produce excellent teams. Excellent organizations, the ones that focus on quality, eliteness, and protecting teams, are also likely to produce jelled teams.

"It's Supposed to Be Fun to Work Here" proposes just that: work should be fun. That doesn't mean that the ideal job would be fun, it means that a good manager can and should make work enjoyable for his charges. Doing different things, such as war games and pilot projects, along with giving people as much freedom to define their own jobs as possible, are good ways to make work fun again. The time to act is now.

What's Good?

As I read this book, I felt that every paragraph had something to say. D&L are constantly throwing out important points, backed by data or their own experience. Everyone who works as an "intellect worker" can likely relate to some of the problems in this book, and the points presented can improve any workplace. Pick this book up, read it, and find something to improve. Your coworkers will thank you for it.

What's Bad?

While I can't say there's anything bad about this book, the audience is a little more focused than some books I've reviewed here. Independent contractors, or others who tend to work on their own, and people who don't live at a desk probably won't relate to a lot of this book.

What's In It For Us?

Redhat had better conform to this book, or else.... No, just kidding. Seriously, in terms of "open source" relevance, I'm sure you can configure your virtual office any way you like. However, given that a jelled team is much more productive than random groups of people, it would seem that team-directed efforts should try to strengthen the committee as much as possible.

Purchase the book over at Amazon.

• Acknowledgements
• Preface

1. Managing the Human Resource
   1. Somewhere Today, a Project Is Failing
   2. Make a Cheeseburger, Sell a Cheeseburger
   3. Vienna Waits for You
   4. Quality -- If Time Permits
   5. Parkinson's Law Revisited
   6. Laetrile
2. The Office Environment
   1. The Furniture Police
   2. "You Never Get Anything Done Around Here Between 9 and 5"
   3. Saving Money on Space
   • Intermezzo: Productivity Measurement and Unidentified Flying Objects
   1. Brain Time Versus Body Time
   2. The Telephone
   3. Bring Back the Door
   4. Taking Umbrella Steps
3. The Right People
   1. The Hornblower Factor
   2. Hiring a Juggler
   3. Happy to Be Here
   4. The Self-Healing System
4. Growing Productive Teams
   1. The Whole Is Greater Than the Sum of the Parts
   2. The Black Team
   3. Teamicide
   4. A Spaghetti Dinner
   5. Open Kimono
   6. Chemistry for Team Formation
5. It's Supposed to Be Fun to Work Here
   1. Chaos and Order
   2. Free Electrons
   3. Holgar Dansk

• Notes
• Bibliography
• Index

Continuing his voyage, Jason Bennett has submitted his review of Peopleware. This is a book about how to run an office in the age of the "information worker". Not about coding, but about creating environments in which the work we are all used can be done. So, if you are interested (or have a manager who should read this), click below. Peopleware author Tom DeMarco and Timothy Lister pages publisher Dorset House rating 10/10 reviewer Jason Bennett ISBN 0-932633-05-6 summary An excellent book about how an office should be run. If you consider yourself an "intellect worker," read this book and apply its principles. Background

I apologize for the missed week. I was finishing up my report for work on this book, and didn't get around to my Slashdot review. I've also ended up changing the schedule, since this review was available, and Creating a Software Engineering Culture would have required duplicating a lot of work. Anyway, we'll get to it next week. I'm also currently reading Built to Last, an excellent book about what makes the difference between a decent company and a great ("visionary") company. I'm not sure that review belongs on Slashdot, but reader demand will help to influence that. :-)

What's the book about?

Peopleware is the collected knowledge of two long-time project managers. Specifically, they deal with what is wrong with how managers treat their people, and what is wrong with the work environment itself. The book talks in terms of software projects, but is useful to anyone who falls in to the category of "intellect worker"; in other words, those people who need to concentrate to work, as opposed to those who work in "interrupt mode."

Peopleware is organized into many separate, but related, essays. Once again, I'll be dealing with the book in chunks:

1. Managing the Human Resource (ch. 1-6)
2. The Office Environment (ch. 10-13)
3. The Right People (ch. 14-17)
4. Growing Productive Teams (ch. 18-23)
5. It's Supposed to Be Fun to Work Here (ch. 24-26)

"Managing the Human Resource" deals with how intellect workers should be treated. The main theme of the book is summed up on page 4: "The major problems of our work are not so much technological as sociological in nature." Ultimately, projects do not fail because people cannot understand the technology, but because the team itself breaks (or is broken). Workers must be treated as people, not as parts of a machine. So much of managerial theory assumes some sort of non-intellectual, "assembly line" development (be it a car plant or burger joint). Using these kinds of adversarial, non-thinking tactics will ruin an environment of people who are paid to think. Because those workers think, each one is unique and irreplaceable. You can't mine your "human resources" from the ground.

"The Office Environment" is one of the most focused, devastatingly effective parts I've read in a while. D&L systematically demolish the theory of cheap, open space, the notion that the environment does not effect people, and the notion that workspace is the place to save money. Consider that the cost of a worker's space is 1/20th of his salary over the average time he stays at one company (2 years). If a poor environment hampers that worker's productivity, the money saved in building that environment will be more than overshadowed by the extra time required for the worker to complete tasks. In fact, there are 11:1 differences in productivity between the best and worst organization. Should you be working 10 times more than you should?

The thesis behind "The Right People" is that it is critical to hire the best people in the first place, as a manager is not likely to mold a worker himself. Therefore, managers should strive to hire the people who will do the best job and complement the team the most, not the people who will most conform to some arbitrary standard. Allowing teammates to assist in the process, and keeping a long-term focus to reduce turnover, will help the situation.

"Growing Productive Teams" focuses on the concept of "jelled teams." These teams, where the members are highly focused on the goal, are much more productive than the individual members could ever be. These teams are difficult to make, but easy to destroy. Managers who give their people freedom and trust are most likely to produce excellent teams. Excellent organizations, the ones that focus on quality, eliteness, and protecting teams, are also likely to produce jelled teams.

"It's Supposed to Be Fun to Work Here" proposes just that: work should be fun. That doesn't mean that the ideal job would be fun, it means that a good manager can and should make work enjoyable for his charges. Doing different things, such as war games and pilot projects, along with giving people as much freedom to define their own jobs as possible, are good ways to make work fun again. The time to act is now.

What's Good?

As I read this book, I felt that every paragraph had something to say. D&L are constantly throwing out important points, backed by data or their own experience. Everyone who works as an "intellect worker" can likely relate to some of the problems in this book, and the points presented can improve any workplace. Pick this book up, read it, and find something to improve. Your coworkers will thank you for it.

What's Bad?

While I can't say there's anything bad about this book, the audience is a little more focused than some books I've reviewed here. Independent contractors, or others who tend to work on their own, and people who don't live at a desk probably won't relate to a lot of this book.

What's In It For Us?

Redhat had better conform to this book, or else.... No, just kidding. Seriously, in terms of "open source" relevance, I'm sure you can configure your virtual office any way you like. However, given that a jelled team is much more productive than random groups of people, it would seem that team-directed efforts should try to strengthen the committee as much as possible.

Purchase the book over at Amazon.

• Acknowledgements
• Preface

1. Managing the Human Resource
   1. Somewhere Today, a Project Is Failing
   2. Make a Cheeseburger, Sell a Cheeseburger
   3. Vienna Waits for You
   4. Quality -- If Time Permits
   5. Parkinson's Law Revisited
   6. Laetrile
2. The Office Environment
   1. The Furniture Police
   2. "You Never Get Anything Done Around Here Between 9 and 5"
   3. Saving Money on Space
   • Intermezzo: Productivity Measurement and Unidentified Flying Objects
   1. Brain Time Versus Body Time
   2. The Telephone
   3. Bring Back the Door
   4. Taking Umbrella Steps
3. The Right People
   1. The Hornblower Factor
   2. Hiring a Juggler
   3. Happy to Be Here
   4. The Self-Healing System
4. Growing Productive Teams
   1. The Whole Is Greater Than the Sum of the Parts
   2. The Black Team
   3. Teamicide
   4. A Spaghetti Dinner
   5. Open Kimono
   6. Chemistry for Team Formation
5. It's Supposed to Be Fun to Work Here
   1. Chaos and Order
   2. Free Electrons
   3. Holgar Dansk

• Notes
• Bibliography
• Index

Back from his vacation, Jason Bennett has written a review of Code Complete. Written by Steve McConnell, this takes a good overview of coding constructs, style and technique. Click below if you want to read more, and if anyone is interested in doing reviews, drop me a line. Code Complete author Steve McConnell pages publisher Microsoft Press rating 9/10 reviewer Jason Bennett ISBN 1-55615-484-4 summary

Everything you should have learned in school, but didn't. Steve gives a complete overview of coding techniques and methods suitable for anyone who writes code.

> Background

Greetings, all. Good to be back on Slashdot after a few weeks away for vacation (in Costa Rica!) and general rest. This week, my McConnell butt-kissing spree continues with his first book, Code Complete. I'll be continuing my reviews next week with a somewhat more focused book, Creating a Software Engineering Culture by Karl Wiegers, followed by two of Tom DeMarco's books, PeopleWare and The Deadline. By that time, who knows, I might have read some more!

What's the book about?

As I said above, this book is everything you should have learned in school, but were too busy hacking to hear. It is a very complete discussion of coding constructs, style, and technique. It's helpful when using any language, on any platform, for whatever goal. In short, if you write code, you can learn from this book.

This book is massive, so for simplicity's sake, I'll deal with it in the following chunks:

1. Laying the Foundation (ch. 1-3)
2. Design (ch. 4-7)
3. Data (ch. 8-12)
4. Control (ch. 13-17)
5. Constant Considerations (ch. 18-22)
6. Quality Improvement (ch. 23-26)
7. Final Steps (ch. 27-30)
8. Software Craftsmanship (ch. 31-33)

"Laying the Foundation" sets up the mental constructs and prerequisite work for software construction. Specifically, he describes the metaphors common to software development and the requirements needed before solid construction can begin. These prerequisites foreshadow Steve's future works, Rapid Development and Software Project Survival Guide, and give a solid, short list of preliminary project needs. Steve's approach here shows that he understands that good development is more than a tight loop or a slick language. That loop is only meaningful to the extent that it fulfills the goal of the project, a goal which must be clear and correct in order to guide the course of the project. Remember that the next time you spend three hours on a nasty module, only to discover that your module isn't needed. Neglecting the preliminaries will only waste your time.

"Design" describes what is needed to set up high-quality routines, including steps for building routines, what a good routine needs and doesn't need, modularity and various design methodologies. Remember, your code's overall structure will largely dictate its maintainability, as well as its debuggability and testability. The better you do here, the easier things will go toward the end.

"Data" drills down one level further, and moves us into the actual code. Although constructing data types is de-emphasized in a true OO environment (such as Smalltalk or Java), those C(++) addicts out there will be dealing with this issue until time immortal. Steve spends plenty of time on data naming, including Hungarian Notation. Scourge to some, savior to others, I don't personally like HN itself, but love the idea of a solid naming convention. However you choose to name your types, calling them mwindsgty won't help you, or anyone else. Steve also discussing variables, including those evil global ones, along with fundamental types and complex types. Mostly an overview of CS101, but there are plenty of useful tips thrown in to boot (especially if you never HAD CS101).

"Control" deals with those most important structures, the decision constructs. If and case statements are addressed here, along with loop controls, gotos (everyone boo here), and my favorite of all, recursion (pointers just aren't the same without it). Again, much of this is basic, but if you never learned it, need a refresher, or need to do it properly, reading it will teach you plenty.

"Constant Considerations" moves out of the actual statements and into other considerations, such as style, self-documenting code, and useful tools. If you are dealing with an external layout standard (such as the GNU standards), you can't apply your own technique, but at least use TAB in Xemacs if nothing else! And comment, dangit! If you saw the evil DOS code I have to maintain, you'd understand why I feel that way....

"Quality Improvement" gives a good overview of Quality Assurance/Quality Control issues, as well as unit testing/debugging techniques. Steve also trumpets peer reviews as an excellent way to remove defects from code. In fact, code reviews can improve code in multiple ways at once. The code itself is checked for accuracy, new techniques are discussed among programmers, and the team is enhanced for having done something well together. Software quality is something we all want, but don't always know how to achieve. This can help.

"Final Steps" takes us through the end-game of development: system integration, tuning and maintenance/evolution. Steve gives some excellent tips on when and when not to tune software. Generally, wait until the last minute before turning your code into a morass of tricks. Document heavily. Above all, make sure you really need it. Usually, the compiler will do better than you, anyway.

"Software Craftsmanship" is a more personally oriented chapter, dealing with character and crafting issues. I'm glad Steve took the time to address these important topics, which sometimes are shoved away by ego-centered considerations. Remember, you code for people, not machines, and you code with people, not machines.

What's Good?

As I said last week, Steve knows what he's doing. This book won some awards for its excellence, and is truely a thorough overview of the coding, and generally the development, process. This is the sort of book you read through once, to make sure you see everything, and then refer to consistently. Make sure you pay attention to those sections on testing and naming, so that your next OSS project will be better for everyone involved.

What's Bad?

It's hard to say anything is bad about CC, although its length is probably its largest detriment. The book is so comprehensive, you'll likely need to pare down the parts you don't need from what's important to you (just like an encyclopaedia). Fortunately, there are good summaries at the end of each chapter that can be copied and referred to at will. It would probably also be a good idea to highlight/copy the relevant parts for easy reference. Also, remember that this book focuses on coding. The other sections are nice, but companion books on testing and requirements/design will be needed.

What's In It For Us?

I don't have to stand on by soapbox quite so shrilly this time. :-) Clearly, good, clean coding is a necessity to any large, long lived project (not that you'd realize that from seeing some code...). These techniques will make anyone a better coder, even if you've seen it all before. We all need review, and we all learn things even when we did think we could. Solid, stable, reviewable, readable, open-source code is our greatest tangible asset. This book will only strengthen that asset.

Purchase the book over at Amazon.

• Checklists

• Reference Tables
• Preface

• Laying the Foundation
  1. Welcome to Software Construction
  2. Metaphors for a Richer Understanding of Programming
  3. Prerequisites to Construction
• Design
  1. Steps in Building a Routine
  2. Characteristics of High-Quality Routines
  3. Three out of Four Programmers Surveyed Prefer Modules
  4. High-Level Design in Construction
• Data
  1. Creating Data
  2. The Power of Data Names
  3. General Issues in Using Variables
  4. Fundamental Data Types
  5. Complex Data Types
• Control
  1. Organizing Straight-Line Code
  2. Using Conditionals
  3. Controlling Loops
  4. Unusual Control Structures
  5. General Control Issues
• Constant Considerations
  1. Layout and Style
  2. Self-Documenting Code
  3. Programming Tools
  4. How Program Size Affects Construction
  5. Managing Construction
• Quality Improvement
  1. The Software-Quality Landscape
  2. Reviews
  3. Unit Testing
  4. Debugging
• Final Steps
  1. System Integration
  2. Code-Tuning Strategies
  3. Code-Tuning Techniques
  4. Software Evolution
• Software Craftsmanship
  1. Personal Character
  2. Themes in Software Craftsmanship
  3. Where to Go for More Information
• Bibliography
• Index

Hetz Ben Amo sent this link my way and daywalker also wrote "It appears that Dan Shaffer of "Project Heresy" fame will be covering be covering Linux news once a week in their CNET Radio webcast... Check out the good stuff "We'll be covering Linux news & views every Thursday in CNET Radio's 1:00 p.m. PT webcast, starting September 3. You can also catch each episode on-demand from this page." "

In a truimphant sophmore return, Jason Bennett has sent us in a review of Software Project Survival Guide. Part of ongoing series of books reviwed by Jason, the goal is to walk through a number of valuable software engineering books. For the full scoop, check below. Software Project Survival Guide author Steve McConnell pages publisher Microsoft Press rating 9/10 reviewer Jason Bennett ISBN 1-57231-621-7 summary

Steve gives a good once-over of the software development process, and backs it up with good examples and on-line documentation.

Background

This being the second review in my series of software engineering books (process and management being key components of said concept), I thought it would be good to give an overview of where we are, and where we're going. Last week, we looked at Frederick Brooks' Mythical Man-Month , the seminal classic of software management. This week, we'll be looking at the latest book by a new classic author, Steve McConnell. Now, I might as well say right upfront that Steve is a Microsoftie (at least part-time). You can take that as praise or criticism, but it's truth nonetheless. Fortunately, Steve is above idol worship, and thus his books are quite palatable, even if you have to support the Evil Empire in the process. No matter who he consults for, however, Steve knows what he's talking about. In the end, that's what matters. We'll be staying in Steve country for this week and next (his Code Complete is next), after which we'll move on. For now, however, enjoy this review/summary of Software Project Survival Guide.

What's the book about?

To a large extent, this book is the culmination of many years of writing on Steve's part. His previous books are Code Complete, which focuses on the details of writing code well, and Rapid Development, which focuses on the software lifecycle, with some management thrown in for good measure. Now, with Software Project Survival Guide, Steve has written a quick-pass tutorial on how to deal with getting a program out the door. One major focus of this book is on process, that is following the steps of development closely to catch problems as early as possible. Echoing a sentiment expressed by Brooks, Steve points out that the earlier a problem is caught, the cheaper it is to fix. It's dang easier to erase a line on a whiteboard than to rip out multiple modules/objects full of code and correct them (a lesson which my project at work is currently learning).

The book is divided into four major parts:

1. The Survival Mind-Set
2. Survival Preparations
3. Succeeding by Stages
4. Mission Accomplished

The first part addresses the underlying concepts of the book (process, finding problems early, what a successful project looks like, etc), giving the reader an understanding of what it means to properly take a project through the valley of the shadow of failure. Steve also first mentions the concept of "staged delivery" in this part, something he will harp on throughout the book. Basically, staged delivery is how most open-source projects run: having multiple release dates with integral increases in functionality. For vertical or internal applications, however, this is a rarity. When software is driven to a releasable stage multiple times, it establishes the exact state of the software, allowing for better schedule estimation and allows the user to obtain a minimal, but possibly critically functional, piece of software early. Staged delivery differs from multiple versions released over time in that the final staged delivery fulfills one set of requirements stated at the beginning, while multiple versions will each have a unique set of requirements (which will typically bloat for every further release).

Part II addresses the initial, planning phases of a project, before actual detailed work is done. This includes oversight boards (of varying size, just as long as someone is reviewing the decisions), effective configuration management, risk analysis, and scheduling. Requirements are also done at this point, an architecture crafted, and QA/QC brought on board. At this point, everyone who will be involved should know what is going on, and all planning and infrastructure should be in place. Unfortunately, this stage has a tendency to drag on, as people waffle over who will do what, and what exactly will be done. My project in particular experienced some serious delays in this area, as the customers were incapable or unwilling to tell us what they needed, and when they needed it, beyond "everything, in a month." We finally got past this point, but not without wasting way too much time.

Part III digs into the meat of the process -- keeping on track while the software is being written. Brooks addresses this part of the process in MMM with his famous quote, "More programming projects have gone awry for lack of calendar time than for all other causes combined." The man speaks truth. Steve takes the project through stage planning, detailed design, construction, testing and release. These steps will then be repeated for each stage of the project, until all stages are completed. As discussed earlier, this will allow maximum delivery in a minimum time, especially of critical features. Steve also emphasizes "miniature milestones" to better gauge where the project is. There's a true saying that "90% of the project is done 90% of the time." Of course, what that really means is that no one really ever knows how much of the project is completed. However, setting small, concrete milestones all along the timeline will allow an excellent gauge of where the project is. "How does a project get to be a year late? One day at a time. (Brooks)"

Part IV discusses the project aftermath, especially learning from the project. This is a short part, and mainly emphasizes archiving all documentation and reviewing what went right and what went wrong. Steve also offers a nice list of project management resources, including other books and web sites.

What's Good?

Steve McConnell is a proven author, and as such does not disappoint. The chapters are clear and concise, with excellent checklists at the end of each. He also has an entire website devoted to supporting the book. He steps through the process methodically, making sure all parts are covered. For those of you interested in the SEI's CMM practices, Steve has drawn heavily from them for this book. My understanding is that Steve is not wedded to the model itself, although he certainly sees it as an excellent step forward. In fact, following the recommendations of this book will definitely bring a project closer to level 2 compliance.

What's Bad?

Well, if I thought the book wasn't useful, I wouldn't have reviewed it. :-) Anyway, the book does not have any glaring flaws. I think Steve tends to emphasize organizations that need five member change boards over those where the board is likely to be the manager (which is probably most organizations). If, however, you can adapt his ideas to your situation, you and your project will benefit.

What's In It For Us?

Once again, where does Open Source come into this? I'm going to end up repeating myself somewhat from last week, but I am firmly convinced that open source projects need more process and structure. The software community has managed to survive for forty years with little process, and open source has done the same for twenty. Now, however, that chapter must end. We need increased productivity and better organization to be truly effective. We need written requirements to keep the projects on track and stop the waste of time and effort that non-required code brings. We need solid design (and detailed design) to keep everyone on the same page. We already do staged delivery (to some extent), but we need to pre-document when and how this will happen, instead of putting out a release when we feel like it. Too many projects wander off into oblivion because of gold plating or lack of vision and purpose. The better we can focus our passions and efforts, the closer to victory we will come.

Purchase the book over at Amazon.

• Table of Contents

• Acknowledgements
• Preliminary Survival Briefing

1. The Survival Mind-Set
   1. Welcome to Software Project Survival Training
   2. Software Project Survival Test
   3. Survival Concepts
   4. Survival Skills
   5. The Successful Project at a Glance
2. Survival Preparations
   1. Hitting a Moving Target
   2. Preliminary Planning
   3. Requirements Development
   4. Quality Assurance
   5. Architecture
   6. Final Preparations
3. Succeeding by Stages
   1. Beginning-of-Stage Planning
   2. Detailed Design
   3. Construction
   4. System Testing
   5. Software Release
   6. End-of-Stage Wrap-Up
4. Mission Accomplished
   1. Project History
   2. Survival Crib Notes

• Epilogue
• Notes
• Glossary
• Index

In a truimphant sophmore return, Jason Bennett has sent us in a review of Software Project Survival Guide. Part of ongoing series of books reviwed by Jason, the goal is to walk through a number of valuable software engineering books. For the full scoop, check below. Software Project Survival Guide author Steve McConnell pages publisher Microsoft Press rating 9/10 reviewer Jason Bennett ISBN 1-57231-621-7 summary

Steve gives a good once-over of the software development process, and backs it up with good examples and on-line documentation.

Background

This being the second review in my series of software engineering books (process and management being key components of said concept), I thought it would be good to give an overview of where we are, and where we're going. Last week, we looked at Frederick Brooks' Mythical Man-Month , the seminal classic of software management. This week, we'll be looking at the latest book by a new classic author, Steve McConnell. Now, I might as well say right upfront that Steve is a Microsoftie (at least part-time). You can take that as praise or criticism, but it's truth nonetheless. Fortunately, Steve is above idol worship, and thus his books are quite palatable, even if you have to support the Evil Empire in the process. No matter who he consults for, however, Steve knows what he's talking about. In the end, that's what matters. We'll be staying in Steve country for this week and next (his Code Complete is next), after which we'll move on. For now, however, enjoy this review/summary of Software Project Survival Guide.

What's the book about?

To a large extent, this book is the culmination of many years of writing on Steve's part. His previous books are Code Complete, which focuses on the details of writing code well, and Rapid Development, which focuses on the software lifecycle, with some management thrown in for good measure. Now, with Software Project Survival Guide, Steve has written a quick-pass tutorial on how to deal with getting a program out the door. One major focus of this book is on process, that is following the steps of development closely to catch problems as early as possible. Echoing a sentiment expressed by Brooks, Steve points out that the earlier a problem is caught, the cheaper it is to fix. It's dang easier to erase a line on a whiteboard than to rip out multiple modules/objects full of code and correct them (a lesson which my project at work is currently learning).

The book is divided into four major parts:

1. The Survival Mind-Set
2. Survival Preparations
3. Succeeding by Stages
4. Mission Accomplished

The first part addresses the underlying concepts of the book (process, finding problems early, what a successful project looks like, etc), giving the reader an understanding of what it means to properly take a project through the valley of the shadow of failure. Steve also first mentions the concept of "staged delivery" in this part, something he will harp on throughout the book. Basically, staged delivery is how most open-source projects run: having multiple release dates with integral increases in functionality. For vertical or internal applications, however, this is a rarity. When software is driven to a releasable stage multiple times, it establishes the exact state of the software, allowing for better schedule estimation and allows the user to obtain a minimal, but possibly critically functional, piece of software early. Staged delivery differs from multiple versions released over time in that the final staged delivery fulfills one set of requirements stated at the beginning, while multiple versions will each have a unique set of requirements (which will typically bloat for every further release).

Part II addresses the initial, planning phases of a project, before actual detailed work is done. This includes oversight boards (of varying size, just as long as someone is reviewing the decisions), effective configuration management, risk analysis, and scheduling. Requirements are also done at this point, an architecture crafted, and QA/QC brought on board. At this point, everyone who will be involved should know what is going on, and all planning and infrastructure should be in place. Unfortunately, this stage has a tendency to drag on, as people waffle over who will do what, and what exactly will be done. My project in particular experienced some serious delays in this area, as the customers were incapable or unwilling to tell us what they needed, and when they needed it, beyond "everything, in a month." We finally got past this point, but not without wasting way too much time.

Part III digs into the meat of the process -- keeping on track while the software is being written. Brooks addresses this part of the process in MMM with his famous quote, "More programming projects have gone awry for lack of calendar time than for all other causes combined." The man speaks truth. Steve takes the project through stage planning, detailed design, construction, testing and release. These steps will then be repeated for each stage of the project, until all stages are completed. As discussed earlier, this will allow maximum delivery in a minimum time, especially of critical features. Steve also emphasizes "miniature milestones" to better gauge where the project is. There's a true saying that "90% of the project is done 90% of the time." Of course, what that really means is that no one really ever knows how much of the project is completed. However, setting small, concrete milestones all along the timeline will allow an excellent gauge of where the project is. "How does a project get to be a year late? One day at a time. (Brooks)"

Part IV discusses the project aftermath, especially learning from the project. This is a short part, and mainly emphasizes archiving all documentation and reviewing what went right and what went wrong. Steve also offers a nice list of project management resources, including other books and web sites.

What's Good?

Steve McConnell is a proven author, and as such does not disappoint. The chapters are clear and concise, with excellent checklists at the end of each. He also has an entire website devoted to supporting the book. He steps through the process methodically, making sure all parts are covered. For those of you interested in the SEI's CMM practices, Steve has drawn heavily from them for this book. My understanding is that Steve is not wedded to the model itself, although he certainly sees it as an excellent step forward. In fact, following the recommendations of this book will definitely bring a project closer to level 2 compliance.

What's Bad?

Well, if I thought the book wasn't useful, I wouldn't have reviewed it. :-) Anyway, the book does not have any glaring flaws. I think Steve tends to emphasize organizations that need five member change boards over those where the board is likely to be the manager (which is probably most organizations). If, however, you can adapt his ideas to your situation, you and your project will benefit.

What's In It For Us?

Once again, where does Open Source come into this? I'm going to end up repeating myself somewhat from last week, but I am firmly convinced that open source projects need more process and structure. The software community has managed to survive for forty years with little process, and open source has done the same for twenty. Now, however, that chapter must end. We need increased productivity and better organization to be truly effective. We need written requirements to keep the projects on track and stop the waste of time and effort that non-required code brings. We need solid design (and detailed design) to keep everyone on the same page. We already do staged delivery (to some extent), but we need to pre-document when and how this will happen, instead of putting out a release when we feel like it. Too many projects wander off into oblivion because of gold plating or lack of vision and purpose. The better we can focus our passions and efforts, the closer to victory we will come.

Purchase the book over at Amazon.

• Table of Contents

• Acknowledgements
• Preliminary Survival Briefing

1. The Survival Mind-Set
   1. Welcome to Software Project Survival Training
   2. Software Project Survival Test
   3. Survival Concepts
   4. Survival Skills
   5. The Successful Project at a Glance
2. Survival Preparations
   1. Hitting a Moving Target
   2. Preliminary Planning
   3. Requirements Development
   4. Quality Assurance
   5. Architecture
   6. Final Preparations
3. Succeeding by Stages
   1. Beginning-of-Stage Planning
   2. Detailed Design
   3. Construction
   4. System Testing
   5. Software Release
   6. End-of-Stage Wrap-Up
4. Mission Accomplished
   1. Project History
   2. Survival Crib Notes

• Epilogue
• Notes
• Glossary
• Index

A review of the venerable The Mythical Man-Month was sent our way by Jason Bennett. While this book has some years on it, the fact that it is still around is a testament to the strength of the text. This latest addition contains additional essays and thoughts about engineering. So, click below and enter into the wonderful world of software engineering. The Mythical Man Month: Essays on Software Engineering - Anniversary Edition author Frederick P. Brooks, Jr. pages publisher Addison Wesley Publishing Company, Inc. rating 10/10 reviewer Jason Bennett ISBN 0-201-83595-9 summary

As a classic software engineering text, this book is only helped by the addition of Brooks' latest essays and reflections on his original conclusions. Remember, it won't do you any good unless you read it.

Background

Before I lauch into my review of The Mythical Man Month, I would be negligent if I did not explain the meaning of the first edition of this book. It's 1975. Programmers slave over some of the earliest dumb terminals on massive mainframes from the Great Monopolistic Satan of computing, IBM. Maybe, if their lucky, the programmers can work on a minicomputer from that upstart company, DEC, and their PDP series of computers. FORTRAN and COBOL are your staples, with some PL/I thrown in for good measure. C is a blip on the horizon, just starting to make its way out of Bell Labs. Assembly language is still widely used throughout the industry. Enter Frederick Brooks, one of the industry's originals. Brooks is reflecting on his time at IBM, specifically his working on the System/360 and its operating system, OS/360 (unique names, no?) during the mid-1960's. Brooks is trying to figure out what was done right, and what was not, especially in how the overall progam was structured and managed. He thus sets out to write one of the first treatises on software project management, an indispensible part of software engineering. Twenty-five years later, we are still reading the book and learning from it. In an industry where most books are useless after six months, this book is almost prehistoric. Remember, though, what level a book must reach to last so long.

What's Good?

You might be wondering why this book has lasted so long. The answer is simple: the technology of the book is secondary to the people lessons. Simply put, Brooks' points are the following:

1. Programming must turn into software engineering in order to continue to improve the state of the art.
2. Any well-engineered product must be conceptually and architectually whole.
3. The tar pit of software development can only be escaped through a conscientious, dedicated process.

There are so many classic lines in this book that a simple review cannot account for them all. The most famous, of course, is Brooks' Law of adding people to a late project (hint: it doesn't help). Surgical development teams, the second-system effect, and the importance of documentation are all covered, sometimes for the first time, in MMM. Through the course of the book, Brooks covers all fascets of what must happen to successfully complete a major software project, and in all parts he gives a firm foundation for solid software engineering and project management. In fact, this was the first major book to accurately assemble the knowledge needed to engineer a large software project into one place, and relate it from the perspective of a finished project.

In addition to the original chapters, Brooks' essay from 1986, No Silver Bullet, is included, along with Brooks' thoughts on his book twenty-five years later. These essays alone are worth reading, as they give an accurate estimate of where the industry is now. Suffice to say, the easy part is behind us. It's real work from here on in.

What's Bad?

What's bad about this book is that people don't read it. There's no particularly good reason, they just are too busy reading the latest book on today's fad. The irony, of course, is that today's fad will be laughed at next year, while MMM will still be around a decade from now. If you were assigned this book in school, read it again (you probably didn't the first time :-). If you've never heard of it, read it tomorrow.

What's In It For Us?

Why should any of us read this book? What does project management matter to a bunch of semi-organized groups? Aren't we doing fine as it is in our striving for World Domination? Well, yes and no.

On one hand, we don't have the pressures of commercial software. If Apache comes out tomorrow instead of today, no matter. Everyone else is just as bad, so we just have to not be worse. For that matter, most open-source projects are blessed with one or a few leaders who keep everything on track and in one vision. We don't have too many projects with lots of different architects.

On the other hand, we've been blessed with low expectations. No one expected us to succeed, so any measure of success was a victory for the movement. Now, all eyes are on us. If a release comes out a month late, everyone will think we're no better at keeping a schedule than Microsoft. If we have to rewrite another application because we did a poor design job, we aren't offering a valid alternative. We have to be better than everyone else to prove ourselves, and we cannot do that in an individually-oriented environment. If the open-source community can learn the lessons of MMM better than the rest of the industry, than we win.

More to the point, we as an industry must raise our expectations of our software. We need to strive for accurate schedules. We need to avoid the second-system effect. We need to understand why you cannot just add people to a late project to speed it up. In short, we need to care about producing quality software on time, instead of just getting stuff out there.

More to Come

This is the first in what I hope will be a series of reviews of software engineering book. My current company is trying to move to CMM level 2, and as part of that our Process Group is reading a series of books. Some of them are business or interpersonal oriented, but some others (like MMM) are software related. Hopefully, I'll kick out a review a week.

The net effect of this, I hope, is to get the open-source community interested in producing a complete, quality product instead of just neat functionality. In order for a program and project to last in the spotlight, it must have solid underpinnings. Only through applying the principles of software engineering can open-source projects fully achieve greatness.

Purchase the book over here at Amazon.

• Table of Contents

• Preface to the 20th Anniversary Edition
• Preface to the First Edition
  1. The Tar Pit
  2. The Mythical Man-Month
  3. The Surgical Team
  4. Aristocracy, Democracy, and System Design
  5. The Second-System Effect
  6. Passing the Word
  7. Why Did the Tower of Babel Fail?
  8. Calling the Shot
  9. Ten Pounds in a Five-Pound Sack
  10. The Documentary Hypothesis
  11. Plan to Throw One Away
  12. Sharp Tools
  13. The Whole and the Parts
  14. Hatching a Cataastrophe
  15. The Other Face
  16. No Silver Bullet - Essence and Accident
  17. "No Silver Bullet" Refired
  18. Propositions of The Mythical Man-Month: True of False?
  19. The Mythical Man-Month after 20 Years
• Epilogue
• Notes and References
• Index

A review of the venerable The Mythical Man-Month was sent our way by Jason Bennett. While this book has some years on it, the fact that it is still around is a testament to the strength of the text. This latest addition contains additional essays and thoughts about engineering. So, click below and enter into the wonderful world of software engineering. The Mythical Man Month: Essays on Software Engineering - Anniversary Edition author Frederick P. Brooks, Jr. pages publisher Addison Wesley Publishing Company, Inc. rating 10/10 reviewer Jason Bennett ISBN 0-201-83595-9 summary

As a classic software engineering text, this book is only helped by the addition of Brooks' latest essays and reflections on his original conclusions. Remember, it won't do you any good unless you read it.

Background

Before I lauch into my review of The Mythical Man Month, I would be negligent if I did not explain the meaning of the first edition of this book. It's 1975. Programmers slave over some of the earliest dumb terminals on massive mainframes from the Great Monopolistic Satan of computing, IBM. Maybe, if their lucky, the programmers can work on a minicomputer from that upstart company, DEC, and their PDP series of computers. FORTRAN and COBOL are your staples, with some PL/I thrown in for good measure. C is a blip on the horizon, just starting to make its way out of Bell Labs. Assembly language is still widely used throughout the industry. Enter Frederick Brooks, one of the industry's originals. Brooks is reflecting on his time at IBM, specifically his working on the System/360 and its operating system, OS/360 (unique names, no?) during the mid-1960's. Brooks is trying to figure out what was done right, and what was not, especially in how the overall progam was structured and managed. He thus sets out to write one of the first treatises on software project management, an indispensible part of software engineering. Twenty-five years later, we are still reading the book and learning from it. In an industry where most books are useless after six months, this book is almost prehistoric. Remember, though, what level a book must reach to last so long.

What's Good?

You might be wondering why this book has lasted so long. The answer is simple: the technology of the book is secondary to the people lessons. Simply put, Brooks' points are the following:

1. Programming must turn into software engineering in order to continue to improve the state of the art.
2. Any well-engineered product must be conceptually and architectually whole.
3. The tar pit of software development can only be escaped through a conscientious, dedicated process.

There are so many classic lines in this book that a simple review cannot account for them all. The most famous, of course, is Brooks' Law of adding people to a late project (hint: it doesn't help). Surgical development teams, the second-system effect, and the importance of documentation are all covered, sometimes for the first time, in MMM. Through the course of the book, Brooks covers all fascets of what must happen to successfully complete a major software project, and in all parts he gives a firm foundation for solid software engineering and project management. In fact, this was the first major book to accurately assemble the knowledge needed to engineer a large software project into one place, and relate it from the perspective of a finished project.

In addition to the original chapters, Brooks' essay from 1986, No Silver Bullet, is included, along with Brooks' thoughts on his book twenty-five years later. These essays alone are worth reading, as they give an accurate estimate of where the industry is now. Suffice to say, the easy part is behind us. It's real work from here on in.

What's Bad?

What's bad about this book is that people don't read it. There's no particularly good reason, they just are too busy reading the latest book on today's fad. The irony, of course, is that today's fad will be laughed at next year, while MMM will still be around a decade from now. If you were assigned this book in school, read it again (you probably didn't the first time :-). If you've never heard of it, read it tomorrow.

What's In It For Us?

Why should any of us read this book? What does project management matter to a bunch of semi-organized groups? Aren't we doing fine as it is in our striving for World Domination? Well, yes and no.

On one hand, we don't have the pressures of commercial software. If Apache comes out tomorrow instead of today, no matter. Everyone else is just as bad, so we just have to not be worse. For that matter, most open-source projects are blessed with one or a few leaders who keep everything on track and in one vision. We don't have too many projects with lots of different architects.

On the other hand, we've been blessed with low expectations. No one expected us to succeed, so any measure of success was a victory for the movement. Now, all eyes are on us. If a release comes out a month late, everyone will think we're no better at keeping a schedule than Microsoft. If we have to rewrite another application because we did a poor design job, we aren't offering a valid alternative. We have to be better than everyone else to prove ourselves, and we cannot do that in an individually-oriented environment. If the open-source community can learn the lessons of MMM better than the rest of the industry, than we win.

More to the point, we as an industry must raise our expectations of our software. We need to strive for accurate schedules. We need to avoid the second-system effect. We need to understand why you cannot just add people to a late project to speed it up. In short, we need to care about producing quality software on time, instead of just getting stuff out there.

More to Come

This is the first in what I hope will be a series of reviews of software engineering book. My current company is trying to move to CMM level 2, and as part of that our Process Group is reading a series of books. Some of them are business or interpersonal oriented, but some others (like MMM) are software related. Hopefully, I'll kick out a review a week.

The net effect of this, I hope, is to get the open-source community interested in producing a complete, quality product instead of just neat functionality. In order for a program and project to last in the spotlight, it must have solid underpinnings. Only through applying the principles of software engineering can open-source projects fully achieve greatness.

Purchase the book over here at Amazon.

• Table of Contents

• Preface to the 20th Anniversary Edition
• Preface to the First Edition
  1. The Tar Pit
  2. The Mythical Man-Month
  3. The Surgical Team
  4. Aristocracy, Democracy, and System Design
  5. The Second-System Effect
  6. Passing the Word
  7. Why Did the Tower of Babel Fail?
  8. Calling the Shot
  9. Ten Pounds in a Five-Pound Sack
  10. The Documentary Hypothesis
  11. Plan to Throw One Away
  12. Sharp Tools
  13. The Whole and the Parts
  14. Hatching a Cataastrophe
  15. The Other Face
  16. No Silver Bullet - Essence and Accident
  17. "No Silver Bullet" Refired
  18. Propositions of The Mythical Man-Month: True of False?
  19. The Mythical Man-Month after 20 Years
• Epilogue
• Notes and References
• Index

bleachboy writes "We all know about VA Research and their fine complete system solutions for Linux, but I am the type of nerd who likes to put my computer together piece-by-piece. Can anyone recommend a hardware vendor (i.e. mobos, memory, cpu's, etc) who is known to be Linux-friendly? Not that it matters particularly when buying piecemeal hardware, but I like to support companies worthy of support! :) "

Brian Bernstein writes "Just incase you didn't get enough with FishCam, LitterBox Cam and other assorted items, Netscape's Engineering department has reverse engineered a surplus bus sign and has created a web page for you to enter your own messages to be displayed to the department and the world. Worth a look if you've got a few minutes... " Boy I've seen some crazy things in my day, and this is right up there.

Sixty4Bit wrote in to tell us about an article at ZDNet's Developer.com about Java Video games. The cool part is that apparently I got some write in votes for Java Invaders. Thanks guys.

Prasanth Kumar sent us this MicroTimes article which lists the top 100 people of 97 (I guess anyway) and lo and behold, there is Linus, with yet another mysterious reference to whatever-the-heck-transmeta reference. Linus, if you read this, send me email and tell me what you do! *big smile*