Book Review - Software Estimation: Demystifying the Black Art

Software Estimation: Demystifying the Black Art by Steve McConnell is a book that meets my definition of a good technical book.

In my opinion, Estimation is an underrated subject. A lack of understanding of this topic among team members (not just the PM) can negatively impact the success of the project. This is because the Project Manager has to draw on the judgement & experience of the software development team as well. This book is written for developers, leads, testers, and managers who need to create estimates occasionally as one of their many job responsibilities. It gently guides the reader through the esoteric art of software estimation with lots of practical real-world advice.

Within the 300+ pages of the book spread across 23 chapters, the author explains 32 Estimation techniques graded according by these factors of applicability:

1. What's estimated (Size, Effort, Schedule, Cost, Features) 
2. Size of project (Small, Medium, Large)
3. Development stage (Early, Middle, Late), 
4. Whether the development style is iterative, sequential, or both 
5. Accuracy possible (Low, Medium, High)

The well-researched content is interspersed with 118 tips, numerous facts drawn from other authoritative books on software estimation and interesting statistics. Tip #30 contains the mantra of estimation: Count if at all possible. Compute when you can't count. Use judgment alone only as a last resort. 

Tip #17 advices: Include time in your estimates for stated requirements, implied requirements, and nonfunctional requirements—that is, all requirements. Nothing can be built for free, and your estimates shouldn't imply that it can. He lists the nonfunctional requirements that also need to be taken care of -

1. Accuracy
2. Interoperability
3. Modifiability
4. Performance
5. Portability
6. Reliability
7. Responsiveness
8. Reusability
9. Scalability
10. Security
11. Survivability
12. Usability

As with his other books, the author sets clear expectations. He explicitly states where the estimation techniques mentioned in the book will not be useful -

This book is not about how to estimate the very largest projects—more than 1 million lines of code, or more than 100 staff years.

These techniques will not produce estimates that are accurate to within ±5%, but they will reduce estimation error to about 25% or less, which turns out to be about as useful as most projects need, anyway. 

He informs in the beginning that this book draws from both the art and science of software estimation, but its focus is on software estimation as an art. This book avoids deep math and emphasizes relatively simple practices. Steve McConnell plans to publish a companion volume in the future that will deal with the Science of Estimation and cover more mathematically intensive estimation approaches.

I feel this book is essential reading for anyone who is into software development & highly recommend it.

Related:

• 10 Deadly Sins of Software Estimation
• Book Review: Software Project Survival Guide

Read More

Book Review: Head First PMP

I purchased Head First PMP after a PM friend recommended me that book as a good starter guide to taking the PMP certification. As he mentioned & others have vouched, no one book including this one can help you pass the exam. What this book does is that it makes learning Project Management concepts enjoyable. This was my first book in the Head First series. I liked the book's unusual, non-linear style (with things like notes in the margins) of presentation although the excessive use of goofy pictures put me off a bit. The tone throughout is very informal, friendly & conversational which makes the guide engaging.

The 42 processes which form the core of the PMBOK (Project Management Body of Knowledge) Guide, 4th Edition and cross-cut 9 Knowledge Areas & 6 Process Groups are explained well. Processes grouped by Knowledge Area make up a chapter. Besides the 9 chapters focusing on the Knowledge Areas, there are 6 more which cover the preliminaries & practice tests with answers. Important points in them are reiterated & highlighted. 2 complete chapters including a Practice test are available for free download. You could check these out & see if the book suits you before you buy it.

On the negative side, there are some typos & errors that you would have to look out for. I found some of the examples in the book to be too unrealistic & contrived to be of practical benefit.

Summary: Whether or not you are taking the exam, I feel this is a good guide on Project Management to start with if you are an aspiring PM or one by circumstance.

Read More

Book Review: In the Trenches with Microsoft Office Project 2007

Project 2007 is a complex & powerful tool for Project management. By taking over the number crunching & analysis part, it helps Project Managers conserve time and focus on decision making aspects. In the Trenches with Microsoft Office Project 2007 by Elaine Marmel shows how to use Project 2007 for various Project management situations in about 350 odd pages. In a part cookbook, part tutorial style the author takes the reader through common scenarios that a PM can face, suggests best practices and offers useful tips.

As the author admits, this book is not specifically a guide for Project 2007. It is ill-suited for beginners to Project 2007. It does not target any specific edition of Project 2007. I feel the contents could have been organized and presented in a better way to make it more engaging. I love it when key points are summarized at the end of each chapter (as in Code Complete or some of the Microsoft Certification guides). That way, the gist of the chapters are sticky & more memorable. I sorely missed it in this book.

If I had to rate this book in Amazon style, I would give it 3 stars out of 5

Trivia - Project 2007 does not have the "Ribbon"

Also see -
HOW TO create a Ribbon-less Excel 2003 UI in Excel 2007

Read More

HOW TO spot a bad apple or a problem team member

A study on team dynamics has found that groups that had a bad apple (a person with a personality type of "Depressive Pessimist" or "Jerk" or "Slacker") would perform worse and other team members begin to take on the bad apple's characteristics.

...the worst team member is the best predictor of how any team performs.

Jeff Atwood writes...

While it's depressing to learn that a group can be so powerfully affected by the worst tendencies of a single member, it's heartening to know that a skilled leader, if you're lucky enough to have one, can intervene and potentially control the situation.

Still, the obvious solution is to address the problem at its source: get rid of the bad apple.

Even if it's you.

So how to spot a bad apple in a team or know if you are turning into a bad apple?

Jeff quotes Steve McConnell on the possible warning signs that you're dealing with a bad apple on your team:

1. They cover up their ignorance rather than trying to learn from their teammates. "I don't know how to explain my design; I just know that it works." or "My code is too complicated to test." (These are both actual quotes.)

2. They have an excessive desire for privacy. "I don't need anyone to review my code."

3. They are territorial. "No one else can fix the bugs in my code. I'm too busy to fix them right now, but I'll get to them next week."

4. They grumble about team decisions and continue to revisit old discussions long after the team has moved on. "I still think we ought to go back and change the design we were talking about last month. The one we picked isn't going to work."

5. Other team members all make wisecracks or complain about the same person regularly. Software developers often won't complain directly, so you have to ask if there's a problem when you hear many wisecracks.

6. They don't pitch in on team activities. On one project I worked on, two days before our first major deadline, a developer asked for the day off. The reason? He wanted to spend the day at a men's clothing sale in a nearby city -- a clear sign he hadn't integrated with the team.

Related: Book Review: Software Project Survival Guide

Read More

Book Review: Software Project Survival Guide

"How does a project get to be a year late?... One day at a time" - Fredrick P. Brooks

When you are setting out on a long journey along an unknown path, it pays to seek advice from folks who know that path well. Similarly you can count on the book Software Project Survival Guide by Steve McConnell, the accomplished author of the classics Code Complete and Rapid Development, for guidance on completing your project successfully.

The author draws inspiration from the best practices suggested by numerous Software Project Management publications and his rich experience to prescribe a Staged Delivery approach to tackle small & medium sized projects. His pragmatic & optimistic approach has some elements from the Agile methodology. He emphasizes the power of "Process" and shows how it can lead to better predictability, visibility and control. There was just one instance where I felt this may have been romanticized -

The completed Software Project History provides a useful supplement to each team member's individual memory. Holding a printed, bound history document provides a sense of closure, and each project member should recieve a personal copy.
(Chapter 17, End-of-Stage Wrap-Up)

Having worked for a CMM Level 5 company, I initially detested all the documentation but soon understood the value of metrics and the discipline it enforces which pays dividends in the long run. I agree with the author that "the cost & schedule penalty for having too much process is far smaller than the penalty for having too little process".

Running across some 300 pages, the book is filled with practical recommendations, documentation templates, checklists, dos and don'ts for a newbie Project Manager or Lead on a medium sized project. Overall, I think this is a great reference for software engineering practitioners.

Read More