Customer Reviews

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

5 star:		(12)
4 star:		(1)
3 star:		(4)
2 star:		(4)
1 star:		(1)

 

 

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

Professional Software Development is an updated and significantly expanded edition of my 1999 book, After the Gold Rush.

In edition to updating the content end-to-end, this edition contains several new essays:

3 - Cargo Cult Software Engineering
8 - Raising Your Software Consciousness
9 - Building the Community
11 - Programmer Writing
13 - Business Case for Better Software Practices
15 - Quantifying Personnel Factors
16 - Construx's Professional Development Program

Since 1999, I've also learned a few lessons that are reflected in this new edition:

* Licensing of software developers is more controversial than I expected. I have tried to clarify that licensing is only one of many initiatives needed to improve the software development profession.

* The world didn't fall apart on January 1, 2000. Although I didn't think Y2K would be catastrophic, I did believe that Y2K-related problems would be more significant than there were. Beyond that, the Y2K problem itself was in some sense a result of successful software devel-opment practices. Y2K would not have been an issue in the first place if sys-tems had not survived so much longer than their originally expected life-spans.

* Modern software development is truly impressive in many respects, and any comments about professionalizing the field of software development should account for software's numerous successes. We must be careful not to throw out the field's better practices as we try to strengthen the weaker ones.

The book is organized into four sections.

Section 1, "The Software Tar Pit," explains how the software field got to be the way it is. There are many valid reasons why the software field came to its current state. Understanding those reasons should be used to accelerate, not delay, the changes needed to make successful projects an everyday habit.

Section 2, "Individual Professionalism," looks at the steps individuals can take on their own to achieve higher levels of software professionalism.

Software projects are so complex that numerous key factors cannot be addressed effectively at the individual level. Section 3,"Organizational Professionalism," digs into the organizational practices needed to support more professional software projects.

Section 4, "Industry Professionalism," examines steps that must be taken by the software industry at large to support professionalism at both the individual and organizational levels.

In short, this book describes the trade of computer programming as it exists today and explores the profession of software engineering as it might exist in the future.

The best software organizations control their projects to meet defined quality targets. They accurately predict software delivery dates months or years in advance. They deliver their software projects within budget, and their productivity is constantly improving. Their staff morale is high, and their customers are highly satisfied. It is my hope that this book will be part of a constructive dialog about how to help software development more often reach its full potential.

- Steve McConnell

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.

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!

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.'

It is clear the author cares very deeply about his profession. He is searching for a way to increase software development professionalism. I did not view this book as a how to cook book. I viewed it as a vision book that offers suggestions on what needs to happen for future software development. Viewed in that light the book succeeds well. Unfortunately some of his analogies to other professions show lack of understanding for those professions, but otherwise the book is good food for thought.

If you are looking for a more concrete books on how to develop software now, he has a good reading list in his book Code Complete, second edition chapter 35. Also check his web site: http://www.construx.com/professionaldev/

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.

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.

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.

As the author of the software's industry's classic tomes, "Code Complete" and "Rapid Development", anything by Steve McConnell is required reading. However, I believe that "Professional Software Development" along with its parent text, "After The Goldrush" is highly unlikely to have the impact of his earlier work.

McConnell remains at his best when detailing the problems of the industry and few will argue with his call for the adoption of established best practices and the creation of a better-qualified, structured and more accountable profession. The contentious area is his attempt to base this profession on engineering; a discipline that many feel is not an appropriate metaphor for the distinct and unique task of producing software.

Other industry authorities, in particular, Alan Cooper, have eloquently and convincingly denounced this view of software design and construction as engineering, and it seems to lead the author into some increasingly strange territory, for example his bizarre proposal that prospective software practitioners should study traditional engineering topics!

In swimming against the tide of movements such as Cooper's Interaction Design, Fowler's Agile Development and Beck's Extreme Programming, I would suggest that McConnell's ideas on creating an engineering-based Profession, are unlikely to see widspread adoption outside of the large-scale developers of in-house, scientific applications.

For all this, the book is still an interesting and stimulating read, but I suspect that many are still hoping that McConnell will return to his area of true expertise - the software construction process - and revise Code Complete to incorporate the latest methodologies and environments.