Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers

In this single book, Mr. McConnell has managed to summarize all of the arguments for 'building software the right way'. It is non-intuitive to individuals who have little or no training in software engineering, including programmers. When I used to interview VB programmers my first question was always 'Describe the Implements keyword'. For many business people they feel that if you are not coding then you are not making progress, which is just plain wrong if you are in the early stages of a project. This often puts us (as project leaders) in the position of educating the client. This book is incredibly helpful for just such an endeavor. There are so many great points that I have used in helping me overcome the non-intuitive parts of development. The statistics for our industry are abysmal (in terms of budgets over-runs, cancelled projects, etc.). If everyone read this book, and stopped coding for a few hours and actually THOUGHT more about the problem (especially for OO development - doing UML, CRC Cards or SOMETHING) in my opinion (after coding for 20 years - 13 of them professionally) our industry would be in much better shape. Even better would be if you can get your team using design patterns, pair programming (in many cases this is a good idea but not in all), agile development techniques, and other general `best practices'. I am constantly under pressure to code before it is appropriate to do so. It is hard to explain to a CEO that you need time to do what they believe is 'drawing pretty pictures'. However, reducing dependencies (and when you have them, making them dependent on abstract classes and/or interfaces NOT concrete implementation), not to mention model/view/controller type patterns are the difference between turning on a dime (say adding a web services API in a few weeks) or spending 6 months on a rewrite. I cannot say enough good things about this book. Kind Regards, Damon Carr, CEO agilefactor www.agilefactor.com

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!

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" f

I've been in software development for way too long, but books like this make me glad I'm part of the profession now. Steve McConnell has revised a few chapters in "After the Gold Rush: Toward a Profession of Software Engineering" and added some new essays. The result is even better than ATGR was three years ago when I read it. Steve gave a talk at the SEPG Conference in Seattle and captivated us with a keynote that showed even then that he was ahead of the curve. There are numerous reasons Steve is an editor for IEEE Software, and many of them show here.There are questions about where our profession is going, and quite a few people with differing opinions. No one is talking about what we need to do as clearly as Steve has done in this book. We all need to buy a copy and read it. We should give copies to colleagues and project managers, and start asking what we can do to make things different in the future. Give a copy to the head of the computer science department of your local colleges and universities, and ask when they are starting a software engineering program like the one at RIT. If you live in Texas or Canada, find out about getting your professional license.I work in an organization that was assessed at CMM Level 3 back in December. I work on the SEPG and help us improve the way we do all our work, project management as well as software developmetn. It wasn't until after our assessment was over that I realized much of our software process improvement in the past five years was focused mostly on project management. Knowing this has changed how I approach my job, and brought me back in focus on what I need to working on. Steve's book gave me some great ideas, and I hope to find a way to make many of them happen where I work.You should do the same where you work, whether it is you by yourself or you and 35,000 colleagues all around the world. Change won't happen if we don't do something about this together. This is our future we're talking about, and now we have a few ideas about what we can do to make it different.You need to know. Get this book to find out where to start.