<< 1 >>
Rating: 
Summary: Advice I use in my software engineering class
Review: As I repeatedly tell the students in my software engineering classes, less than twenty percent of the work building a software project involves writing the code. The vast majority of the work is in capturing the requirements, constructing the design, critiquing the requirements and design; getting and incorporating customer feedback; testing the code and verifying that the requirements have been met. In fact, when you add in reasonable time for training and interacting with new tools, the percentage of the effort that is writing code is probably closer to ten percent. If you also add in the time spent organizing all of this effort, then the effort that is actually writing the code is in the area of ten percent and may even be lower.
At least one week of the year is spent in midweek holidays, leaving at most fifty-one weeks of work. I have never seen a compiler upgrade that didn't take at least a week to iron out all the details. Since most tool update cycles are annual and the wise organization is always evaluating new tools, close to five percent of the effort is probably spent in evaluating and integrating new tools. Henry mentions several different problems in this area, he understands that the seamless change of tools is a fantasy, found only in advertising flyers.
Whether you see it in the schedule or not, training also takes up a minimum of five percent of the team effort. Developers either learn as they build or learn before they build, but either way the time is spent.
Choosing the appropriate training is a nontrivial task. With few exceptions, the training needed by any group is different from all others. As Henry points out, when considering training, search out specific details about what is being offered. The training may be excellent, but if it is an overview when you need to know specific details, then it may be of little value to your organization.
The emphasis in this book is on the organizational features that make a project successful, the critical part that is keeping everything within acceptable bounds, from the original idea to the shipping of the product. High quality managers do not have to know a C program from a sea serpent, but they do have to be able to spot potential failure from the other side of the ocean. Most software developers will not admit to significant problems until forced, and the good manager will be able to read body language, tonal inflections and general appearance to determine if things are going well. This is impossible if you do not know the people well and have some familiarity with how they conduct themselves. There is always some degree of tension between boss and worker, but if the employee knows that honesty is rewarded, then the level is lowered.
However, this is just on the reactive side. The good managers are proactive, examining the situation on a regular basis, looking at what should have been done and asking the tough questions to determine if things are on the right course. They also must change the course if necessary, and this can only be done right if you have a set of measurements that accurately describe the current situation. Chapter four is a detailed description of how to choose measurements that apply to your project(s).
Henry explores in detail some of the specific requirements of a software project that are often ignored in other books. In chapter six, the emphasis is on the background requirements, the hardware, software and support needed for the project. The points for hardware are:* Specify what the hardware needs to do.
* Specify what the hardware needs to be functional.
*Specify who needs what hardware.
* Specify when the team needs the hardware. Simple points, but often overlooked both by authors of software project management books and in practice.
The author is clearly someone who has learned from experience, much of which is the best kind, negative. A great deal of the activity in a software development project is now organizational. How to examine and organize the requirements, how to make and carry out the assignments of people to tasks and how to track the progress using processes that actually measure what has been done. The author describes all of this in detail, with advice that I have incorporated into my software engineering classes.
Rating:
Summary: Good Hands On Advice for the First Timer
Review: In reviewing several texts for a project managment class I will be instructing, I found Mr. Henry's the most succinct in addressing "real world" issues. He sets a realistic tone by focusing on a project's culture and its relationship to processes and tools. The text is not loaded down with unproven theory, and each suggested technique or approach is backed up by the author's personal observation, research or solid references. Henry's discussion on process creation is a realistic one, and I like the fact that he doesn't get religious about any particular approach. I believe the text provides a good framework to base a course on, but I would have preferred a stronger emphasis on software architecture and its impact on team productivity. The author gives light treatment to this under a section for quality. Also, while testing is discussed and a rudimentary outline of a testing plan is provided, I would have preferred more treatment of techniques in managing followup as well as the considerations in migrating corrections when further work has been done in other areas of development (i.e. regression testing strategy). Overall, though, this text provides a good start for experienced software engineers running a project for the first time. While the discussion on hardware and software considerations is brief, it highlights an essential check list that is sufficient for an experienced engineer to consider. The price of the book is competitive, but like many of the books in this subject area, I believe the price is a bit much to ask of students.
Rating:
Summary: Good Hands On Advice for the First Timer
Review: In reviewing several texts for a project managment class I will be instructing, I found Mr. Henry's the most succinct in addressing "real world" issues. He sets a realistic tone by focusing on a project's culture and its relationship to processes and tools. The text is not loaded down with unproven theory, and each suggested technique or approach is backed up by the author's personal observation, research or solid references. Henry's discussion on process creation is a realistic one, and I like the fact that he doesn't get religious about any particular approach. I believe the text provides a good framework to base a course on, but I would have preferred a stronger emphasis on software architecture and its impact on team productivity. The author gives light treatment to this under a section for quality. Also, while testing is discussed and a rudimentary outline of a testing plan is provided, I would have preferred more treatment of techniques in managing followup as well as the considerations in migrating corrections when further work has been done in other areas of development (i.e. regression testing strategy). Overall, though, this text provides a good start for experienced software engineers running a project for the first time. While the discussion on hardware and software considerations is brief, it highlights an essential check list that is sufficient for an experienced engineer to consider. The price of the book is competitive, but like many of the books in this subject area, I believe the price is a bit much to ask of students.
<< 1 >>
|
