Schedule and Programming Books

I used to have the Bible book for Microsoft Project as my reference for making the most out of this software for managing projects, until The Missing Manual came out. This title in now-popular Missing Manual series takes you through the basics and not-so-basics for Project Standard and Project Professional, allowing you to understand the when and the why behind its features and helping you better build and refine your project plans, track progress of your projects and succeed as a project manager.

Any who own Microsoft's Project 2007 needs Bonnie Bafore's MICROSOFT OFFICE PROJECT 2007: THE MISSING MANUAL guide, which should really be in the box alongside the program. It offers easy step-by-step instructions that cover both Project Standard and Project Professional, explaining how and why to use some features - an approach which goes far beyond the usual `how to' guide. From using Project in a variety of business applications and incorporating other programs such as Word and Outlook to practically guaranteeing project success, MICROSOFT PROJECT 2007: THE MISSING MANUAL should be on the shelves not only of any serious computer reference library, but any business library and any individual who owns Project 2007 and wants to get the most out of it.

This manual is extremely helpful for both the novice and the veteran user. The introductory section on project management is one of the best I have seen, and worth the price of the book by itself. Entertaining yet concise style. Book is well organized and information is easily found.
Highly recommended.

Where Brook's The Mythical Man Month documents the lessons learned during the development of IBM's OS/360, this 15-year-old book documents the lessons learned during the development of a betting system. The Mythical Man Month focused on project failures (making it probably the first book of anti-patterns), while this book focuses on success. Despite its age this book is probably more valid today than when it was first published, and remains one of the best books on IT project management.

Key points:
(1) Heavy emphasis on getting business requirements and ensuring that the solution that unfolds is aligned to those requirements. This also incorporates scope management from the beginning of the project, which, with requirements, is a make-or-break factor for project success.
(2)How to deal with team issues. One of the recurring challenges that the author faced during the project was how to manage the people part of the equation - his approach epitomizes best practices for controlling meetings, coordinating resources and facilitating trade-offs and managing team and customer expectations. What makes this aspect of the book so powerful is the fact that the project was initiated in 'crunch mode' from the beginning. Leadership and management are key themes throughout this book - something that seems to be often left out in more modern books on IT project management.
(3) Estimating and controlling a dynamic project on the fly are two strong points in this book. Although the project is approached as a traditional waterfall development life cycle, and the technical environment described is archaic, the author's approach is as valid using modern techniques and iterative development life cycles that are currently popular.

What I like: the book is structured around a case study that runs throughout the book. The case study is a real "crunch mode" project that was tossed in the author's lap, and the book is a chronicle of how the project was successfully completed within a compressed timeframe with a hastily thrown together team. This adds credibility to the methods that are presented, all of which still remain as best practices in IT project management. It also makes this slim, 192-page book highly readable (you can read it in an evening). The chapter on Dealing with Disaster should be required reading for all IT project managers. If the appendix, Brief Description of Design Tools, was updated to show mapping to contemporary tools this book would be as fresh today as when it was first published. In addition to this book I recommend Managing a Programming Project: People and Processes, which contains contributions by the author.

While this book may be old, it is one of the tried and true books of project management. I recall this book being standard material for my IT classes as far back as 2000! I still keep it on my bookshelf and read occasionally. A must have for any developer or those who interact with developers in some way...

Like everyone else who has reviewed this book, I give high praises both to the topics in the book and to Steve McConnell's handling of the topics. Not only are the topics extremely well researched and credited, but all areas of the software development life cycle are covered.

This is not just one authors pontification of "one way to do things". It completely covers the various software development methodologies and thoroughly discusses, pros / cons, strengths / weaknesses, pinnacles / pitfalls, use / non-use, of each methodology. These methodologies are all focused around delivery and perceived timeliness of delivery of software projects.
No other book on this subject comes close to completeness or understanding of the software development life cycle and the development efforts needed in order to complete a software task.

Rapid Development is required reading for all developers, IT managers, and software project managers ( even many executives could greatly benefit from this book ).

If you have not read this book, you do not have as full of an understanding of the development process as you think.

"Rapid Development" is an excellent book that covers the software development process.

While the book covers a rapid development strategy, there is great value to be found in the book's coverage of a wide range of software development topics, such as estimating, teamwork and risk management, among other topics.

This book, in my opinion, represents the gold standard in software development reference books. Anyone involved in developing software should add this book to their library.

This book is quite long, but worth every page. As a programmer, one usually gets focused on that - programming. There are however, several dynamics at play at any given software development project: customers, unstable requirements, risks, teamwork, tools, etc. This book presents several fundamental principles, strategies, philosophies and mistakes and than goes to present a set of very important best practices. I highly recommend it!

Took me a couple of months to work through this thick catalog of project management techniques, but worth it I think. It dates back to the late eighties, but is still relevant today. I'm glad I read it.

This is an excellent book for people that want straight facts about the software engineering profession and industry. It is also an excellent source for a plan to understand how to acquire knowledge in search of a better career as a software engineer.

For a long time I tried to find what was the real difference between computer scientists and software engineers because the general knowledge knowadays is that both professions are the same. This book finally gives a clear and straight explanation of the real difference between both.

Another thing I liked a lot about this book is that it refutes the false idea that knowledge in software engineering becomes obsolete too quickly to be useful or to form a body of knowledge.

For all people working in the software industry this is a must-read book to really understand where they should be heading and why.

The main focus of this book in on the creation of a professional software development association or organization, similar to the ones of doctors and arquitects. The discussion is interesting, but not very useful if you have to deal with the problems and challenges of the day-to-day life in software development.

I graduated from a highly specialized program at Virginia Tech that focuses on Engineering Theory - Rocket Science & celestial mechanics (intermediate dynamics), 3 fluid mechanics, etc. with the goal of leading up to Biomechanics concentration. I programmed CAD software and joint-torque analysis physical therapy recommending software as part of my program.

Steve McConnell's association of Software Development to Engineering is a welcome (although at times, not faultlessly backed up) addition to the camp of people like myself who understand firsthand the benefits of Traditional Engineering approaches to Software Development.

Within 4 years of professional experience, I myself was able to secure the top technical position in our industry, Enterprise Architect - one that usually takes 12+ years to even consider.

Do I attribute this to my 152 IQ, impeccable communication skills, or rigorous background in Traditional Engineering? There are lots of people with a VA Tech degree who have high IQs and go through the same communications training. A fundamental flaw I have observed time and time again with my developers is the lack of rigorous problem solving techniques.

When you have spent 2.5 days on a LaPlace Transformation or 6 hours figuring out the angle of an attached pendulum to a moving body in a 3 DOF system in 3D, or deriving acceleration, velocity, and position plots for vibration systems, and you do these things for 4 years straight, often programming to achieve the results, you become a master of elegant problem resolution - engraining into your very being the ability to simplify, breakdown, and attack problems.

My experience in the software industry has proved skeptics like Alan Cooper wrong in my point-of-view. My colleagues and developers are often impressed with my architectures and coding approaches. To me it seems just like second nature - mastering the fundamentals of your technology with a certification, mastering best practices (like Code Complete & CxOne), and mastering inherent problem solving. Then, like the art of Traditional Engineering, there is a beauty to the approach you choose in the art of software design.

Yes. The leaders that will take this industry forward are at NASA and BOEING and increasingly Microsoft. We are Software ENGINEERS, and must embrace that distinction to move forward as a honed, veritable practice in general. Steve McConnell has a good jump start on telling you why - but don't expect an indisputable and flawless argument.

Steve McConnell knows a lot about organising resources to get things done, specifically he knows (probably more than 50,000 things) about getting software done. I appreciate this, and I have benefited greatly from two of his books, the software project survival guide and software estimation; I have also benefited measurably, if to a lesser extent, from another (Code Complete).

Getting things done is a species of management, and an honorable activity, but McConnell is not happy to be a manager (a guy in a suit), he wants to be an engineer (a guy with, at least once upon a time, a slide-rule). His strategy for doing this is to rename his sort of 'organising resources to get things done' as 'software engineering'. Unfortunately, it is not clear to me that he knows, or has thought seriously about, the philosophy of engineering at any level much deeper than that of a self-confident guy in the bar on a Friday evening.

For instance the first thing I saw in my initial leafing was a pair of pictures, of Reims Cathedral, which is cited as an example of 'art without very well developed engineering', and of Sidney opera house, which is contrasted as a paradigm of 'art dependent on engineering'. This says of McConnell first that he knows nothing about the history of european architecture and that he is a dork worthy of Gary Larsen (you don't need any book learning to at least begin to appreciate the sophistication of Reims cathedral as an engineering achievement, all you need to do is to stand in the nave and look up); second that he knows nothing of the very well documented history of Sidney opera house, which is an ornament of the harbour, but is not a usable example of anything to do with scientific engineering (not to mention effective project managment - nor is it even thought a notably good opera house); and third that he is happy to opinionate about things about which he knows nothing and about which he has not even paused to think.

Speaking of which, the second thing I saw is that he does not appear to know much about Francis Bacon other than as a source of pretentious quotations.

If you look at the details, things do not get much better. Consider chapter 13, 'Business case for better software practices'. McConnell wants to argue that the returns on investing in better software development are enormous. This is a plausible claim given the stack of empirical data he quotes, but he does not add anything to the data that he (very helpfully) collects in one place. In another chapter he has complained about 'Cargo Cult Software Engineering', but the subsection 'State of the Practice' here is cargo cult statistical analysis: I could identify no coherent content in it. He also repeatedly says that the gains from investing in improved software processes are even larger for the 'best organisations', but I couldn't figure out what he meant by 'best' - surely the best organisations are the ones that already have good processes in place, and thus have less room for improvement (absent some weird positive feedback loop, which would result in the best organisations disappearing ínto a productivity singularity). I can only assume that by 'best' he means 'rotten, but turn-aroundable'.

A few years ago, I bought a house that needed complete renovation before I moved in; i.e. a new water system, new electrics, etc. The infrastructure that brought mains water and electricity to my house was designed and constructed, and is maintained by engineers. The people who connected my sinks and lights to that infrastructure, on the other hand, were 'plumbers' and 'electricians'. The very competent person who coordinated the work was a 'site manager'.

Equally, the people who built and maintain Oracle are engineers. The vast number of people who build software based on it are almost all 'programmers', while the slightly less vast number of people who coordinate them are 'software project managers'.

This book is a respectable endeavor, to be sure...the title itself makes it sound as if it's going to somehow define a profession in a way that makes us all known quantities. Isn't that what we like to work with anyways? Known quantities? Measurable results?

Unfortunately, there's a critical piece missing: while McConnell throws us some useful practices regarding the definition of our craft and the further measurement of our knowledge, it all sounds like a heap of pet theories and practices that never quite gel into something you can sink your teeth into.

Take for example his chapter devoted to the rigid, complex system he uses in his own company to measure the skill levels of its employees. I looked at it, read the different 'grades', but at the end wanted to know exactly how in practice this made their practice more effective. No dice...just 'here's how we do it, and it's the right way.' No why. No when. No who.

I lost a bit of respect for McConnell after reading this book...Code Complete is a landmark, but after reading
Professional Software Development I felt like he's lost his way amidst the mountains of white papers and the multitudes of 'best-practices.'

Good book on the subject. Pratical coverage of the subject, does not get bogged down in ivory tower approach so common to this subject matter. You will need to tailor their approach to your own situation.

If you took out what was not directly related to the vastly overpriced costXpert product you would have about 10 pages.

This book originally caught my eye because it gave the impression of discussing a variety of estimating techniques from function points to COCOMO. For example the synopsis from amazon.com states, "Powerful, scientific techniques are presented for confidently producing and defending accurate software development estimates and schedules." In my opinion nothing could be farther from the truth. This book should really be titled "A User Manual for CostXPert" which is a copyrighted estimating program developed by the author. It briefly summarizes common estimating techniques in the first two chapters. From chapter three on the text is focused entirely on the CostXPert program. The CostXPert program is included on CD ROM, which is usable for only a six month evaluation period. Of course the author offers to sell you a copy at $995 per license, discounts for larger orders. I am still evaluating the CostXPert software and it could possibly have some merit. The book itself as a means of learning about software project scheduling and cost estimating is woefully inadequate in comparison to other books such as Bary Boehm's "Software Engineering Economics." In fact I am a bit steamed that I spent $50 which is essentially subsidizing the authors marketing costs. If you were interested in the software I would suggest that you go to the authors website and download the program, which comes with a 30 day evaluation. The only benefit that you get with the book is a six month evaluation period instead of 30 days. Caveat Emptor!

I happened across this book in the University of Wisconsin bookstore and picked it up hoping it would expand on things already covered in Boehm's work. As a book, it isn't so great.

However, the software it contains is one of the most usable cost estimation tools around - if you need that kind of tool. In many cases, I've gone through the process that this software shows with other people who bought the tool outright (it's expensive if you're getting it as a single user - if you're buying it for corporate use, it's quite a value). The software is particularly valuable if you're a novice at cost estimation, since you can experiment with different lifecycles, documentation standards, and environmental factors. From this standpoint, the Marotz tool is an excellent educational device.

In short, if you need a software cost estimation tool - download
the free trial version from Marotz and try it out. This book
by itself is probably promising too much.

Nothing more than a poorly written user manual. I was *thoroughly* disappointed. What a waste of money.