Fog Creek Software
Discussion Board




The Career Programmer: Guerilla Tactics for an Imp

Hi Folks

Anyone has read this book? do you recommend it? it's been discussed on slashdot and I was wondering what's your thought on that.

http://www.amazon.ca/exec/obidos/ASIN/1590590082/qid=1060627078/sr=1-1/ref=sr_1_0_1/701-0425384-7671507

Farid
Monday, August 11, 2003

Walmart has it for $19.95, mine is coming tommorrow sometime.

Wayne
Monday, August 11, 2003

Yes, I read it.  I recommended this book in the thread titled, "Office politics - good books".

What exactly do you want to know about the book?

I found the book to be an enjoyable read.  The book is all about how one contractor was able to survive as a contractor and cope with all the craziness that goes on within corporate America.  Did I learn anything new or valuable from this book?  No.

If you are simply looking for reviews of this book then do a Google search.

One Programmer's Opinion
Monday, August 11, 2003

"Guerilla Tactics for an Imp"?

Sounds like a self-defense manifesto for creepy little skinny guys...;-)

Fixed Length
Monday, August 11, 2003


I have something to tell about this book (reading it right now).
Reading is really funny and enjoyable, but the book has some serious flaws
(for me, at least):

1) Being contractor for a long time, author believes everything is a nail:
  every project is "spec -> design -> code -> test -> ship -> that's it".
  Someone else will probably maintain, may be you. For Christ sake, why
  "maintain" ? Projects keep on living, kicking and developing, they don't
  stay on some v1.0 (developed by contractor) forever just to be maintained
  by somebody. So, I think author completely ignores the not-contracting area
  of the software development.

2) Author is a firm follower of the aforementioned "waterfall" project management
  - he never mentions daily builds, unit testing, XP, Agile - whatever new
  technologies and methodologies people came for a while already. No, we're still
  specing, designing, coding, testing, shipping and going home. Which seems
  pretty outdated for someone considering himself a serious software developer,
  IMHO.

So, all his advices are flying above two flaws described above. I've almost
stopped reading it in some point but decided to continue - it still has many
valuable points. To do what he tells us to do ? No, thank you. To have a good
read ? Yes. To adopt some ideas here and there ? Yes.

Have fun !

Evgeny Goldin
Tuesday, August 12, 2003


Well... as a contractor that works for some fairly large corporations... I can affirm without contradiction that the waterfall model is still the "state of the art" in large projects.  Right, wrong or indifferent. 

EDS is now marketing their traditional waterfall under the name of PLM - for Project Lifecycle Management.

Catchy... huh?

Joe AA
Tuesday, August 12, 2003

It's easy to explain - we all know that people hate changes. So we'll see for another years books to come about "spec-design-code-test-ship". Hell, even in my place we're doing waterfall .. Not that I like it.

Evgeny Goldin
Tuesday, August 12, 2003

Evgeny Goldin wrote, "...Which seems pretty outdated for someone considering himself a serious software developer"

Keep in mind that the author probably started writing the book in late 1990s and he based his so called tips on his prior work experience.  I enjoyed reading the book because I could relate to many of the author's work experiences, however, I was also disappointed with his  software development practices/recommendations.

"...Projects keep on living, kicking and developing, they don't stay on some v1.0 (developed by contractor) forever just to be maintained by somebody."

Correct.  My guess is that Mr. Duncan was able to bounce from one "new software development" contract to another throughout his career.


Joe AA wrote, "EDS is now marketing their traditional waterfall under the name of PLM - for Project Lifecycle Management."

EDS and other large consulting firms follow the traditional waterfall process for several reasons.  First, it allows the company to place more bodies on a project.  Second, someone at the firm came up with the methodology several years ago and the company continues to use it because they aren't willing to spend anymore money in this area of software development and "the company's methodology" is an established tool in their marketing bag of tricks.  Third, .....

One Programmer's Opinion
Tuesday, August 12, 2003

I am 100% certain that waterfall methodology is applicable (with slight changes here and there) for all software dev projects. let's not fool ourselves with buzzwords and vapourware.

memyselfandirene
Tuesday, August 12, 2003

*  Recent Topics

*  Fog Creek Home