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

~ (Author)

Editorial Reviews

Product Description

Renowned software expert Steve McConnell helps software students transition to the role of software professionals. Significant developments are afoot that will impact the future careers of student programmers, including initiatives in education, professional development, certification, and licensing. Some of these developments are well thought out and positive; others are being forced and need to be improved before they are standardized. Software development is changing, whether programmers recognize it or not. Programmers who are not paying attention could easily find themselves working as twenty-first century software janitors. This book describes the occupation of computer programming as it exists today and the profession of software engineering as it can exist in the future.

Product Details

• Paperback: 272 pages
• Publisher: Addison-Wesley Professional (July 10, 2003)
• Language: English
• ISBN-10: 0321193679
• ISBN-13: 978-0321193674
• Product Dimensions: 9.1 x 6.9 x 0.7 inches
• Shipping Weight: 1.2 pounds (View shipping rates and policies)
• Average Customer Review: 3.8 out of 5 stars  See all reviews (23 customer reviews)
• Amazon.com Sales Rank: #249,991 in Books (See Bestsellers in Books)

Customer Reviews

Most Helpful Customer Reviews

29 of 31 people found the following review helpful:

5.0 out of 5 stars Another Classic by Mr. McConnell, February 18, 2004

By	Damon Carr "Damon Wilder Carr" - See all my reviews (REAL NAME)

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

26 of 29 people found the following review helpful:

5.0 out of 5 stars Philosophical, but short, sweet, and to the point, December 23, 2003

By A Customer

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.

16 of 18 people found the following review helpful:

5.0 out of 5 stars Role of PEOPLE in software development, September 5, 2003

By	Jeff Olson (Redwood City, CA) - See all my reviews

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!