Peopleware: Productive Projects and Teams

Book Review-Peopleware: Productive Projects and Teams, 2ed

I have to say that I was a bit embarrassed to tell people I was reading Peopleware: Produtive Projects and Teams.  It wasn’t because the material wasn’t good — it definitely is.  It’s not because I felt squeamish about the title — I didn’t.  However, I did feel like I should have somehow managed to have read it before now.  With the original edition written in 1987 and the 2nd edition written in 1999 — I should have read it before now.  Alas, I hadn’t.

Peopleware is, as the title suggests, about people.  It’s about how people and software development fit together.  It’s not another methodology, it’s not a set of programming tips.  It is, however, some interesting insight on how people work, don’t work, and work together.  It has hints of Dilbert in that it talks about the things that managers can do to effectively eliminate productivity within a group.

I collected a few quotes that I believe highlight the value of the book:

  • “The major problems of our work are not so much technological as sociological in nature” (p4)
  • “The statistics about reading are particularly discouraging.  The average software developer, for example, doesn’t own a single book on the subject of his or her work, and hasn’t ever read one.” (p12) [Ouch]
  • “People under time pressure don’t work better; they just work faster.” (p18)
  • “Speaking of software, that industry has accustomed its clients to accept in-house developed application programs with an average defect density of one to three defects per hundred lines of code.” (p21)
  • “People just don’t work effectively when they’re locked into a no-win situation” (p28)
  • “The manager’s function is not to make people work, but to make it possible for people to work” (p34)
  • “People can keep track of only so many human interactions” (p137) [This is particularly interesting if you account for the maximum practical size of a group of people (see The Tipping Point) and the fact that most Agile methodologies work best with smaller groups.]

The book read, to me, as the background information one needs to understand why agile methodologies work.  It’s sort of like reading a book about the internal combustion engine when you drive a car to work every day.  You don’t have to know how the car runs, but when you break down on the side of the road it comes in really handy.

If you’ve not managed to make it through this classic work and you work with others as a manager or as a team member — you should.

Professional .NET 2.0 Generics

Book Review-Professional .NET 2.0 Generics

I was trying to post a comment today to check out a book — a book that I had read and thought I had blogged about but apparently I blogged about it in a dream.  (Yea, I know sick)

The book is Professional .NET 2.0 Generics while I can certainly tear apart some of the mechanics of the book, overall it’s a thorough coverage of the topic both from a breadth and from a depth perspective.  I remember learning more about how the CLR works and the impact of a compile time vs. run-time type generation than I thought possible.

If you’ve got more than a passing interest in generics you should check it out.  You never know, you may just become the generics expert at your organization.

Micro ISV: From Vision to Reality

Book Review-Micro-ISV

When I blogged about Software that Sells: A Practical Guide to Developing and Marketing Your Software Project I commented that there wasn’t much information that was in the book that I didn’t already know.  The guide was really very light on details.  Micro-ISV: From Vision to Reality is a very different story.  I found all kinds of things in the book that were interesting.

I rarely “dog ear” a book these days.  I make it a point to have a pad of paper and pen with me when I’m reading a book.  That’s mostly so I can record my thoughts.  Sometimes I’ll stop reading and start frantically scribbling notes.  Anyway, it’s lead to a lot of books that don’t get “dog eared.”  I even have tape flags that I use to mark what page I’m on — thus no “dog earing.”

However, I haven’t even made it through all of the pages I “dog eared” in Micro-ISV.  There seemed to be a new web site or product that I didn’t know about on every page.  Admittedly Micro-ISV will have a relatively short shelf-life in terms of it’s value because web sites change and companiese go out of business.  However, for now, it’s a great reference for those who are struggling to get a product company going.

The other interesting thing about the book is that it has a great number of interviews in it.  Real people with real problems not unlike your own talking about them.  All in all, a good read.  (I suppose it doesn’t hurt that the author is a former reporter.)

The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP

Book Review-The Rational Unified Process Made Easy: A Practioner’s guide to the RUP

It’s very in vogue to describe your software development process as RUP.  Describing the current methodology as agile (XP, Crystal, Scrum, etc.) evokes too many questions, but describing the methodology as Rational Unified Process, more frequently RUP, leads to fewer questions but puts you ahead of those who are still running a waterfall process.  However, in many cases RUP isn’t really the methodology being used, it’s simply renaming some of the processes and artifacts that were done for waterfall with new names.

The beauty of the book The Rational Unified Process made Easy: A Practitioner’s Guide to the RUP is that focuses not on enumerating the artifacts that one might use with RUP but rather focuses on the core concepts, fundamental precepts, and spirit of RUP.  In this way it intentionally steers the reader away from the natural tendency to try to implement every artifact, to create the highest ceremony process possible.  It provides a balanced view on how to utilize RUP to run effective, successful software development projects.

It also contains a role-by-role review of RUP.  This provides a view of the process from each role’s perspective.  The benefit of this is to condense the amount of training that must be done to get everyone working on the same page.  While they can not be considered a direct replacement for training, the chapters are a good start to helping the team member understand what RUP is all about.

Even in a world enamored with agile, RUP still has it’s place.  It’s proven for larger projects, and provides a path to an iterative model — essential to every form of agile development.  If you’re trying to get to agile RUP is a good stopping point along the way — and the book The Rational Unified Process Made Easy is a good way to understand how to do RUP.

Software that Sells: A Practical Guide to Developing and Marketing Your Software Project

Book Review-Software that Sells: A Practical Guide to Developing and Marketing Your Software Project

Do you know why you don’t see a lot of negative reviews of anything in magazines?  The answer is simple.  Why print something that is negative when you can just as easily print something positive?  Well, the beauty of a blog is that I can post something negative if the item deserves it.  This is one of those cases.

I just finished reading Software That Sells: A Practical Guide to Developing and Marketing Your Software Project.  Actually, there were several sections that I couldn’t force myself to read.

The information contained in the book is trivial, obvious, and sufficiently non-specific so as to be non-actionable.  In other words, this is stuff that nearly everyone knows.  You could buy someone in your area a drink at the local tavern or pub and get a more coherent delivery of useful information.

While I do realize that there are some folks who are very early in their careers who might be able to find value in the broad coverage of topics, most people will find the coverage too trivial.  What is worse, in my opinion, is that the author doesn’t provide the reader good references to go find more information.  There are chapters on marketing and sales, but no references to other books that cover these topics in detail.

So, if you’re trying to figure out how to start a Micro-ISV (small software product company) you may want to keep looking for a good book.  (Micro-ISV by Bob Walsh is on my reading list still.  I’ll let everyone know what I think of it.)

The Tipping Point: How Little Things Can Make a Big Difference

Book Review-The Tipping Point: How Little Things Can Make a Big Difference

If you’ve been reading this blog then you know that I’ve been doing a lot of reading of my own lately, mainly associated with some professional development in the area of reconnecting to basic software development fundamentals that I’m already aware of and some new things as I try to find some new ideas in the various forms of the agile development movement that I can use or try.

The latest book is radically different.  It’s one that was casually mentioned to me by a colleague, Jeff Juday, who was recently awarded Microsoft MVP status.  He mentioned how he thought the program related to the book he had just read, The Tipping Point.

This piqued my interest initially because I’m always curious about how the market works and Jeff promised the book would have some insight.  (He was right.)  Having written (or written part of) 16 books, I know how random sales can be from one title to another.  In fact, when my friends and colleagues approach me about writing a book and ask me if their idea is a good idea, I usually respond with I have no idea.  The market seems to work in mysterious ways.

The Tipping Point is a book about epidemics.  Not so much the negative things as we associate with the word epidemics but rather about things that have a radical growth cycle.

At some point in the book, I wanted to share a passage with everyone I knew.  Some of my mentors, the pastoral staff at the church I attend, my mother, several of my friends, and some of the folks I know at the MVP program at Microsoft.  The truth is that when I finish this blog post many of them will be receiving a link via email to check it out – excluding those I know read my blog regularly and so they’ll see it anyway.

I found the book enthralling as I examined some of the market reactions I had seen.  The birth of the Internet (really the adolescence of the Internet), the growth of cellular phones (which the book discusses), and I even thought about it in terms of SharePoint Portal Server.  (For the record, I would have written this blog post even without a SharePoint tie-in.)

I remember working with the 2001 version of SharePoint Portal Server.  When I’d talk with my peers most of them would be asking me – “Share What?”  There weren’t many people that knew what it was.  Today, when I talk about SharePoint to people I meet – even outside of the industry – I get a surprisingly high awareness rate.  Most don’t know what it does exactly but they know that people think it’s something to watch.  (As a sidebar, most people who do SharePoint work don’t know exactly what it does.)

The interesting thing is looking at this pattern – and others – and evaluating why SharePoint is such a pervasive word in the IT industry and in the minds of small business owners.  It certainly can’t be attributed to the stellar marketing that Microsoft has done for the product.  (Sorry guys.)

Quietly you’ll get some of the marketing folks in the information worker group to admit that there’s a lot of confusion about SharePoint and few places to find good answers.  I’ve had clients pay for us to develop documents that they can use to internally explain the solution – because it’s simply too hard to do without clear documents on what it does and doesn’t do.

SharePoint isn’t successful because of a greater number of people running Microsoft Office.  SharePoint’s popularity can’t be explained by a renewed interest in IT.  It’s an absolute mystery to me as to why it’s become so popular.  (Here’s a challenge – tell me via email why you think it is so popular.  I’d love to hear your perspective.)

The Tipping Point didn’t explain why SharePoint has become so popular but it did give me the clues to look for to identify what happened.  I don’t have the answers but I do at least know some of the questions to ask.  In that way, I think it will be invaluable in the way it allows me to see things more clearly.

The analogy that I’ve come up with to explain it is that it’s like someone with imperfect vision – like myself – putting on glasses for the first time.  It doesn’t make me see or allow me to see for the first time but it does bring more clarity to what I’ve been seeing all along.  The unfortunate thing is that it has also exposed me to how much I still don’t see.

There are some psychological tenants that most people subscribe to – including me.  That I know believe are false.  I’m questioning how much about the way people behave is about their character and how much is about their circumstances.  (In an interesting turn of events, the environment swapping movie Trading Places was on TV last night.)

If you’re the least bit curious about how trends get started and would like to get a little bit better picture of them I highly recommend reading The Tipping Point.

Agile & Iterative Development: A Manager's Guide

Book Review-Agile & Iterative Development: A Manager’s Guide

The latest book to succumb to my ravenous appetite for software development is Agile and Iterative Development: A Manager’s Guide.

More than any of the other books, this book convinced me how astray we’ve all been lead astray by waterfall based development.  While most of my consulting career has been spent adapting waterfall to meet client needs and the needs of the consulting organization, it’s interesting to realize that the fundamental approach to development was wrong.

I particularly liked this books coverage of details.  It talks about how iterative development got started and how current agile practices are linked to iterative development.  It also has great coverage of scrup, xp, up, and evo methodogies — and how they work together well and places where they don’t work together well.

All in all, this is a great guide for people who are open to better understanding what they do well and don’t do well in their software development.

Balancing Agility and Discipline: A Guide for the Perplexed

On Balancing Agility and Discipline: A Guide for the Perplexed

I mentioned briefly in my last post that I was reading Balancing Agility and Discipline: A Guide for the Perplexed.  I managed to navigate my way through the end of the book and wanted to record my initial thoughts about the book and about my growing perspective on Agile software development in general.

On the book…

The fundamental question that the book answers is how do you take the best of Agile development and integrate it into your current software development methodologies.  It neatly disguises this question under the auspicies of exploring the places where each method “belongs.” — their home ground.  It does what appears to be a very thorough job of reviewing the strengths and weaknesses of both traditional (plan-based) development and agile development.

My current thinking about Agile development (and software development in general) is this…

1) Agile software development makes the same statement that traditional development does — better programmers make better projects.  I was struck with how much emphasis good software development –whether traditional or agile — places on good developers.  (It would be more accurate to say good participants.)

2) Agile software development is like Voodoo — at least in the movie Dogma’s definition “Do you know about voodoo? No constitution of faith, more an arrangement of superstitions.”  In other words, it’s a collection of techniques — some shared between different agile variants, some shared with more traditional plan-based development, and some shared with project management practices.  The percentage of people following a specific technique is very low.

3) Agile is akin to “Management by Wondering Around” one of the practices made popular by In Search of Excellence.  It focuses on people actually talking to each other.  Given the number of large scale projects I’ve worked on where that doesn’t happen — I’m all for people talking to each other. 😉  In a more serious way, the focus is on individual and personalized conversations with people.  Answering their specific needs and coaching them into effective behaviors — one by one.

4) The arguments that are being used by both sides of the isle represent a fundamental lack of understanding.  It reminded me of a recent set of posts on the Dilbert Blog about Intelligent Design vs. Evolution.  [Warning: The preceding link may consume a huge amount of time as you try to figure out which of the arguments are the dumbest.]

5) We’re all missing the point … We start good development by getting good people involved.  We get good people involved by DEVELOPING / CREATING / BUILDING good people.  If we’re not all willing to go out of our way to help other people become other developers — every day whether it makes sense to the particular project or not — then we may be doomed to struggle with poor software developers forever.

The good news is, however, I’m more agile than I thought.