<< 1 >>
Rating: 
Summary: Faulty conclusion
Review: I don't agree with everything McConnel says in this book, but it is still the most thoughtful book on software engineering/software development I've read since The Mythical Man-Month. Several other reviewers have said this book is just about licensing software engineers. Did they even read the whole book, or just the chapter on licensing? The book is NOT JUST about licensing! Read it! Sure, there's ONE chapter on licensing, but McConnel's argument is that, to be a real profession, software engineering needs to advance its awareness of the need for better practices, software engineering body of knowledge, university curriculum development, university undergraduate programs, professional code of conduct, and quicker transfer of innovations in software engineering into practice. Licensing is just one piece of the puzzle McConnel discusses. Read it! This book rises above the detailed practical content of McConnel's other books (which are also classics), and distils a more philosophical message for software professionals. It got me thinking about general issues in my career that I hadn't thought about before. I didn't get any specific technical advice from it, but there were a lot of new ideas. 10 years from now I bet this book will actually be more useful in advancing my career than McConnel's other, more detailed, tomes. Anyone interested in software should understand what's involved in establishing a "true profession of software engineering." You can disagree with McConnel's view on licensing software engineers, but don't throw out the other 13 chapters, which discuss equally important aspects of making software more like a profession. Read it!
Rating: 
Summary: The Best Book You Can Read On Software Engineering
Review: I've been in this business since March 1982. I've read them all. This is the BEST book you can read on the subject. I know, you get these books, try to read the first chapter, they're poorly written, boring, and grow dust on your shelf. THIS BOOK IS NOT LIKE THAT! If you read ANY book on software process and the problems currently faced by software professionals, this is it! And, in response to "A reader from Deep in the trenches of software development", grow up! Hopefully, dinosaurs like you will die out, just the way Ptolemaic theory died when Copernican theory was adopted. It's unfortunate that the code-and-fix mental disease persists, mostly in the minds of "heroes, ball-hogs, and silver-bullet all-nighter 24/7" infected programmers. I, personally, went to the University of Michigan College of Engineering, and have a degree called "Computer Engineering". The software field requires all practitioners to elevate themselves to Engineers. One would never dig the foundation for a huge structure without first having solid requirements, design review, blueprints, and permits. The current software field still goes right to digging. The software engineering portion of our profession is the most important: get those requirements, get buy-in, do a design, get it approved. Then, once you're done with that, you can get a programmer to code it! Those of you out there that still do not believe in software process enabling you to meet your goals better than the retched code-and-fix mentality, I ask that you follow leaders with a process and examine the results, or do the rest of us a favor and leave the field.
Rating:
Summary: Persuasive Plea for Professionalism
Review: McConnell's latest book is a highly persuasive plea for software development to mature into a an engineering discipline. Not that all programmers must be licensed engineers, but when an end user needs a program that he can rely on, it will help if there is someone who will stand up to take legal responsibility for their work. Only professionals, such as doctors, lawyers, and architects meet this standard. I want my car's anti-lock braking software written by a certified engineer. My word processor can crash once a week, but not my car. Although some reviewers expressed the fear that licensed engineers would corner the software market and drive all others out of business, this is not McConnell's desire or prediction. There would be plenty of room in the heap for other competent software developers; the proven best would merely be more visible at the top of the heap. This book also serves as an excellent introduction to the kinds of techniques the author recommends in his other books. A manager or department head with less technical knowledge will gain a better appreciation of the challenges of the developers working for them, and why engineers often want to take time out to choose the best method of proceeding, instead of jumping in and producing lines of code.
Rating:
Summary: Required reading for all my employees
Review: Steve McConnell hits the nail on the head: The Software Development profession (I purposly don't call it "Software Engineering Profession") operates very unprofessionally. This book explores some of the reasons and provides solutions. This book is an absolute must-read for every serious software developer!
Rating: 
Summary: Software Engineering as a REAL Profession?
Review: The Tar Pit. Software Dinosaurs. Fool's Gold. Orphans Preferred. Software Engineering is Not Computer Science. These are just a few of the chapter titles from Steve McConnell's latest book, After the Gold Rush. Perusing the table of contents gives one the impression that this read is going to be a hard-hitting call to action, and it doesn't disappoint. After writing some of the best coding, management, and process books of the last decade, McConnell is calling for software development to join the ranks of other real professions as a true engineering discipline. I'm a civil engineer by education, and I can confirm that most software development bears no resemblance to the rigorous discipline exercised by professional engineers. We as an industry have been walking on the wild side for too long. It's time to settle down and get organized. The book is a series of essays that take the reader from the problem, to the search for the solution, and finally to a plan for education and certification. Readers of the author's other books won't be surprised by the analysis of the problems facing the software industry. We--collectively--just put out too much bad software with too many bugs, are still stuck with the Not Invented Here syndrome, and aren't even focusing on the measures that provide feedback for improvement. He promotes the Capability Maturity Model for Software (SW-CMM) as a measure of the practices in wide use today. The report is bleak, and makes software disasters like the Denver airport baggage system, as well as failed software upgrades at the IRS and FAA, seem inevitable. The answer, in overly simplistic terms in this review, is to make software engineering a professional, licensed profession in the same model as civil, mechanical, and electrical engineering. Like those disciplines, this doesn't mean that every practitioner in the field must be educated and licensed as an engineer. But every software project must be signed off by such a professional, who certifies that the project was executed with the proper, rigorous methodologies and built-in safety factors. Like the construction of a log cabin, there would be no need for every relatively simple software application to undergo such rigorous engineering. But any major application would be required to have an engineer overseeing the process. This move is long overdue for the profession. Maybe with it, we'll eliminate the number of major software failures that constantly make the news, and software will once again be as reliable and trusted as the Golden Gate Bridge or the Panama Canal.
Rating: 
Summary: Not an essential read
Review: This book reads like a set of outtakes from the author's excellent "Rapid Development". In fact, some anecdotes, and ideas are repeated from that book without much elaboration. Some interesting insights but some appear to be based on stereotypes. For example, the author claims that many computer science degree courses disregard that most of their graduates will get software engineering jobs and don't teach them necessary skills. CS departments are aware of this and many do include courses on engineering, or the ethics and practices of a "professional". My degree about 5 years ago had these components. I really think this book would have its' point made by having been formed into a few articles for DDJ or Communications of the ACM, or an appendix in "Rapid Development". "Journey of the Software Professional" is a heavier read but a lot more rigorous if you are interested in professional issues in software engineering. An interesting read, if a coworker happens to have a copy lying around, but invest the money in Steve's source material instead - e.g. a copy of "The Capability Maturity Model".
Rating:
Summary: Worth a read.
Review: Thought-provoking book from a guy who's been in the trenches. Maybe I'm biased because for years I've been making the same points within my own small circle. I keep having to do "software archeology" on code that was written by new grads (and old hands who should know better), who are obsessed with writing even the simplest algorithm in a "kewl" way that makes it incomprehensible and unmaintainable, and who keep reinventing the wheel. It makes me wonder if CS departments are teaching anything remotely relevant to industrial software development. The point of this book is not to tell you specifically how to develop robust software - that topic is covered in some of McConnell's other books. This is a call to action on holding software professionals to higher standards and making them take responsibility for the often substandard product they emit. McConnell focuses on certification of software engineers. This is certainly worth exploring but I would like to have seen some discussion of other areas for improvement, such as automated testing and more systematic software reuse. Imagine you have to build the Golden Gate bridge by hand-crafting every rivet - that is the state of software engineering today. Also we should not rush blindly into implementing certification programs. The prospect that a corporation could divert responsibility for its poor business decisions onto a certified software engineer, who simply tried his/her best to implement what the employer asked for, should give us pause. On the other hand, certification should ideally be an engineer's weapon in a death-march situation. If s/he could say "In my professional opinion, what you are asking for, given the time and resources available, is simply not possible", a lot of business fiascos might be avoided. In the end it's a question of educating both management and engineers about the differences between business decisions and technical decisions, and the responsibilities of each party. I expect this book to play a useful role in getting a much-needed debate going.
Rating:
Summary: Must be a different Steve McConnell
Review: Up until his unfortunate conclusion the book is so-so. It takes him many pages to say what most of us know: Many software houses are poorly run, and many managers are not capable. The Discipline of Software Engineering has advanced, no surprise there. Whats needed is for some of the successful methods to be taught in school. It takes more than being the manager of a couple of projects adn reading a couple of books. The field has matured and a more rigorous study is required. So far so good. The obvious solution is to require computer science majors to take 2-3 courses in software engineering and project management. UML should be taught in college and so should CMUs CMM-SW. But then the author climbs the pulpit and demands that software engineers get licensed. Please! Talk about self-serving job security and un-needed regulations. As if the difference between a good manager and a bad one is just following a few guidelines. The authors approach would introduce unwanted and un-needed burocracy, while having no impact on imrpoving quality.
Rating:
Summary: Bureaucracy is not the answer
Review: Uses the analogy of moving stone blocks to illustrate how smart teams continuously look for ways to work efficiently. The author explains how the code-and-fix development pattern is fool's gold. The relationships of computer science vs. software engineering and engineering vs. art are analyzed. Software engineering is defined as the application of scientifically developed and mathematically defined algorithms, functional design methods, quality-assurance methods, and other practices to the development of software products and services. The SW-CMM rating system is explained including the performance benefits of a Level 5 organization. Table 9-1 examines the current status and maturity of software engineering as a profession in the categories of initial professional education, accreditation, skills development, certification, licensing, professional development, professional societies, code of ethics, and organizational certification. An outline for the software engineering body of knowledge is presented. The licensing and specialization of professionals acts as a filtering system. The chasm between "early adopters" and "early majority" in technology innovation is analyzed in respect to the software engineering profession.
<< 1 >>
| 
