Rating: 
Summary: Amazing Insights from my guru!
Review: Steve McConnell became my personal guru after Rapid Development, That book opened my eyes to best software practices. Code Complete is required reading. His new book Professional Software Development is more philosophical. He describes how to be a true professional. Also what companies need to do to become more professional, and what the whole software industry needs to do. Steve is my guru because he says that people and process BOTH matter. Good people using good processes are better than good people using bad processes. Bad people are bad no matter what processes they use. Steve's writing is wonderful and easy to read. My manager must read this book! Thanks Steve!
Rating: 
Summary: Heavy on opinion, light on content
Review: The assessment of engineering, especially around how many people will be certified, leave nothing to argue with, though they're so forward-looking as to be somewhat irrelevant to a developer today. More interesting are his statements about running projects and professional development -- his company has the most compelling reward structure I've ever seen, and far outshadow's MSFT's baroque system.Unfortunately, the lack of *any* mention of Agile methodologies made this book look like either the author has been in Tahiti for the last few years or is trying to subtly discount them. Either way, you read it and say, "yes, this is exactly what Lean addresses; so what's your point?". It was also a little short on concrete recommendations, and comes off more as a position statement on where he'd like software development to be N years from now. I'm glad that I read it because I generally like McConnell's writing and like to hear different opinions on certification of software developers, but I can't say that I'd suggest anyone else bother.
Rating:
Summary: A book all programmers should read and think deeply about
Review: The main theme of the book is that software developers should be given the opportunity to obtain a state-sanctioned license similar to those of physicians, dentists and civil engineers. To obtain such a license, it would be necessary to undergo extensive training and pass a qualifying exam. The benefits of such a properly constructed program are obvious. Once you obtain a license, your income would most certainly rise dramatically. Also, in the case of software where failure could cost lives, it is comforting to know that those who wrote it were highly trained and very qualified. Professional programs could also help if legal action is ever taken against you. The American legal system has repeatedly dictated that you can be sued for malpractice only if you violate the professional rules of conduct in a situation. If you follow the rules, then you cannot be successfully sued for malpractice.
There is of course a down side to such a program. Implementation would be complex and it would have to be phased in using stages. Not all programmers would be able to achieve such a high level of expertise, and quite frankly, not all have a need to do so. Computing is also somewhat rare as a field, in that some of the greatest success stories involve people who were not highly trained. While computing is indeed maturing into a profession where the "code warrior" is a thing of the past, traditions and myths die very slowly.
McConnell is dead on in the position he takes. He comes down strongly in favor of having a program of licensing developers, although he considers it suitable primarily for programmers writing code where lives are at stake. He correctly points out that the bulk of developers will not need to undergo such extensive training. He also effectively uses the analogy of the medical profession. Physicians are organized into specialties, from family practice to the most specialized of surgeons. However, there are many tiers of medical workers such as nurses and physicians assistants, who are just as essential, but require much less training.
The point in the book that should be taken most seriously is that of having a professional code of conduct, which includes ethics and the necessity of following sound development processes. Very few programmers, and I am not one of them, have avoided being asked by a superior to hack out a solution to a problem by violating some (most?) of the rules of sound software creation. If such a code of conduct were to exist, then all programmers who subscribe would have a strong argument to use in facing down a superior who wants code developed using strategies in violation of sound policies.
One other point that may be used in favor of such a licensing program is that it may slow down the apparent mad rush to outsource software development. If enough U.S. programmers demonstrate such a high level of skills, then it will be incumbent and maybe even necessary for U.S. organizations to use them rather than "cheaper" foreign programmers. Such a licensing program will of course eventually diffuse outside the U, S. borders, but that will take years.
It is time for the programming community to drop several myths, and move towards higher levels of professionalism. Bridges had to collapse and people had to die before governments began to regulate those who designed and built bridges, and it is in everyone's interest that this not be repeated in computing. McConnell makes a compelling case for such regulation and I strongly encourage everyone to read this book and give his views the deep thought that they deserve.
Rating:
Summary: Role of PEOPLE in software development
Review: This book explains what people, companies, and the software industry need to do to become more professional. The "Cargo Cult Software Engineering" essay was one of the best I've read -- great distinction between competence vs. work style. I enjoyed the chapter on personal attributes of programmers -- it helped to explain some of the programmers I've had trouble getting along with. The chapter about Construx's professional development program was useful too, and I'm going to try to adapt parts of that to use in my own company. McConnell lays out what can be done at the individual level to become more professional, both now and in the future when educational programs become more readily available. The chapter on "quantifying personnel factors" was great -- McConnell clearly understands that software is produced by PEOPLE, and people have to come first. There is also lots to do at the organizational level, most of which can be done right now. I agree with his argument that good people will naturally want to use good practices, and so the best organizations will want both good people and good practices. How to fully support people working at a truly professional level is the key question. Overall, if you want to understand why sometimes software projects work and sometimes they fail, and if you want to understand what to do to make them succeed every time, this is a great book. Two enthusiastic thumbs up!
Rating:
Summary: Role of PEOPLE in software development
Review: This book explains what people, companies, and the software industry need to do to become more professional. The "Cargo Cult Software Engineering" essay was one of the best I've read -- great distinction between competence vs. work style. I enjoyed the chapter on personal attributes of programmers -- it helped to explain some of the programmers I've had trouble getting along with. The chapter about Construx's professional development program was useful too, and I'm going to try to adapt parts of that to use in my own company. McConnell lays out what can be done at the individual level to become more professional, both now and in the future when educational programs become more readily available. The chapter on "quantifying personnel factors" was great -- McConnell clearly understands that software is produced by PEOPLE, and people have to come first. There is also lots to do at the organizational level, most of which can be done right now. I agree with his argument that good people will naturally want to use good practices, and so the best organizations will want both good people and good practices. How to fully support people working at a truly professional level is the key question. Overall, if you want to understand why sometimes software projects work and sometimes they fail, and if you want to understand what to do to make them succeed every time, this is a great book. Two enthusiastic thumbs up!
Rating:
Summary: Philosophical, but short, sweet, and to the point
Review: This book is a brilliant, enjoyable explanation of the steps we can take to make our projects and software organisations run better. To realize the benefit of this book, you must actually Read The Book, which some of the other amazon reviewers have apparently not yet been able to fit into their busy schedules. The reviewer of 'examples of bad management' never read past the first section, which is called 'The Software Tarpit.' It is indeed about why projects are poorly managed, but it is only 55 pages out of 225. Sections 2, 3 & 4 contain abundant specific suggestions about how to meet schedules, budgets, and other project goals. The reviewer of 'heavy on opinion, light on content' says he reads 5 books a day. The book has numerous notes at the end of each chapter, and is impressively well researched. I surmise this reviewer missed the 'content' during his speed reading. The reading-impaired agile revolutionaries criticise the book for not discussing agile. This book also does not discuss object-oriented design, the Rational Unified Process, East Indonesian basket weaving, or the tooth fairie because those are different topics. Apparently some people think that every book should discuss agile, regardless of the book's topic. This book is short, sweet, and to the point. It does not tell you how to debug your current project (see the author's Code Complete for that), but it will tell you how you and your organisation can improve in the long run. My company has already realised benefits from adopting the ideas in this book, and it is mandatory reading for programmers and managers.
Rating:
Summary: Hello Big Process And Certification
Review: This book is a guide for running most software organizations into the ground. The author is correct in identifying "code and fix" as a bad way of developing software, but the material here is swing too far in the other direction. McConnell suggests that certification and licensing for software engineers is the way to improve software along with adherence to ISO and/or CMM. Certification only implies that someone can pass a test, but it does not show that they can create quality, useful software. Also, the rate of change of technology for software development is too high to support licensing. The ACM pulled out of the SWEBOK effort for this reason. "Code and fix" is a problem, but McConnell does not present a reasonable solution. Look at Pete McBreen's "Software Craftsmanship" for a better alternative and more information as to why certification and licensing is not the way to go. I will say that the chapter on Meyers-Briggs Type Indicator for software developers is very intersting, and it gives some insight into the kind of people that excel at developing software. Even books that are way off base can provide a good nugget here and there.
Rating:
Summary: Hello Big Process And Certification
Review: This book is a guide for running most software organizations into the ground. The author is correct in identifying "code and fix" as a bad way of developing software, but the material here is swing too far in the other direction. McConnell suggests that certification and licensing for software engineers is the way to improve software along with adherence to ISO and/or CMM. Certification only implies that someone can pass a test, but it does not show that they can create quality, useful software. Also, the rate of change of technology for software development is too high to support licensing. The ACM pulled out of the SWEBOK effort for this reason. "Code and fix" is a problem, but McConnell does not present a reasonable solution. Look at Pete McBreen's "Software Craftsmanship" for a better alternative and more information as to why certification and licensing is not the way to go. I will say that the chapter on Meyers-Briggs Type Indicator for software developers is very intersting, and it gives some insight into the kind of people that excel at developing software. Even books that are way off base can provide a good nugget here and there.
Rating:
Summary: A Roadmap for Software Professionals
Review: This is a book written for the software engineer/developer/programmer/analyst (collectively called "developers" in my review). The book basically acts as a roadmap for improving yourself as a developer, making yourself more valuable to your current and future employers (whether they realize it or not). This book introduced me to Steve McConnell's Professional Development Ladder, a way of evaluating your current level of professionalism and learning what areas of knowledge you need in order to progress. It also talks about software engineer licensing (Texas does it), the newly accredited Software Engineering degree program (this replaces Computer Science in many respects), and the Software Engineering Institute's Code of Ethics and Professional Practice. Many of these resources can be found around the Net, but this book neatly consolidates a lot of information. It also includes a lot of information (mainly statistics) I would not have found elsewhere, such as ROI's for specific software engineering practices (simply measuring productivity can return 150% in 12 months or 600% over 36 months, page 116), the exact makeup of the huge productivity gap between different developers (communication factors alone account for a 53% productivity difference, page 137), and an interesting and realistic diagram showing how professional licensing affects the pool of good and bad developers. The roadmap extends all the way from the entry-level developer or new high-school graduate all the way up to industry leadership. I give this book 5 stars not for the book alone but for it combined with the resources at McConnell's web site. If you want to excel in your field as a developer, these two taken together give a lot of great advice.
Rating:
Summary: A Roadmap for Software Professionals
Review: This is a book written for the software engineer/developer/programmer/analyst (collectively called "developers" in my review). The book basically acts as a roadmap for improving yourself as a developer, making yourself more valuable to your current and future employers (whether they realize it or not). This book introduced me to Steve McConnell's Professional Development Ladder, a way of evaluating your current level of professionalism and learning what areas of knowledge you need in order to progress. It also talks about software engineer licensing (Texas does it), the newly accredited Software Engineering degree program (this replaces Computer Science in many respects), and the Software Engineering Institute's Code of Ethics and Professional Practice. Many of these resources can be found around the Net, but this book neatly consolidates a lot of information. It also includes a lot of information (mainly statistics) I would not have found elsewhere, such as ROI's for specific software engineering practices (simply measuring productivity can return 150% in 12 months or 600% over 36 months, page 116), the exact makeup of the huge productivity gap between different developers (communication factors alone account for a 53% productivity difference, page 137), and an interesting and realistic diagram showing how professional licensing affects the pool of good and bad developers. The roadmap extends all the way from the entry-level developer or new high-school graduate all the way up to industry leadership. I give this book 5 stars not for the book alone but for it combined with the resources at McConnell's web site. If you want to excel in your field as a developer, these two taken together give a lot of great advice.
| 
