Once again, Steve McConnell helps software practitioners become software professionals. Significant developments are afoot that will impact the careers of practicing 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.

Amazon.com® Reader Reviews (Ranked by Helpfulness)

Average Amazon.com® Rating:  Based on 23 Ratings

Surprise ! A disappointing book by Steve McConnel - 2009-03-20
Reviewer Rating:
Are these people reviewing the correct book? I'm compelled to write this because I really disagree with the favorable reviews here. This book is a waste of money.

Let me start by saying that I have enjoyed many of Steve McConnel books. I still reference RAPID DEVELOPMENT at work. I like how practical and pragmatic he is in his books. So, I quickly bought this book when I saw it.

Well, this one is a dud. The main premise is that we need professionalism and training in this area to get good and consistent results. There is a lot of discussion about the importance of this to get quality, success etc but that's it. There is really not much insight here. 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.'

I am very disappointed with the book. In fact, I found it so useless that I ended up doing something I normally do not do with my technical books: I threw away the book !!!

If you are interested in the book, take your time to evaluate the content and value to you. It is not as good as his previous books.

Sorry. I like Steve's other books like CODE COMPLETE and RAPID DEVELOPMENT but this one did not do it for me.

middle brow - 2007-05-17
Reviewer Rating:
Steve McConnell knows a lot about organising resources to get things done, specifically he knows (probably more than 50,000 things) about getting software done. I appreciate this, and I have benefited greatly from two of his books, the software project survival guide and software estimation; I have also benefited measurably, if to a lesser extent, from another (Code Complete).

Getting things done is a species of management, and an honorable activity, but McConnell is not happy to be a manager (a guy in a suit), he wants to be an engineer (a guy with, at least once upon a time, a slide-rule). His strategy for doing this is to rename his sort of 'organising resources to get things done' as 'software engineering'. Unfortunately, it is not clear to me that he knows, or has thought seriously about, the philosophy of engineering at any level much deeper than that of a self-confident guy in the bar on a Friday evening.

For instance the first thing I saw in my initial leafing was a pair of pictures, of Reims Cathedral, which is cited as an example of 'art without very well developed engineering', and of Sidney opera house, which is contrasted as a paradigm of 'art dependent on engineering'. This says of McConnell first that he knows nothing about the history of european architecture and that he is a dork worthy of Gary Larsen (you don't need any book learning to at least begin to appreciate the sophistication of Reims cathedral as an engineering achievement, all you need to do is to stand in the nave and look up); second that he knows nothing of the very well documented history of Sidney opera house, which is an ornament of the harbour, but is not a usable example of anything to do with scientific engineering (not to mention effective project managment - nor is it even thought a notably good opera house); and third that he is happy to opinionate about things about which he knows nothing and about which he has not even paused to think.

Speaking of which, the second thing I saw is that he does not appear to know much about Francis Bacon other than as a source of pretentious quotations.

If you look at the details, things do not get much better. Consider chapter 13, 'Business case for better software practices'. McConnell wants to argue that the returns on investing in better software development are enormous. This is a plausible claim given the stack of empirical data he quotes, but he does not add anything to the data that he (very helpfully) collects in one place. In another chapter he has complained about 'Cargo Cult Software Engineering', but the subsection 'State of the Practice' here is cargo cult statistical analysis: I could identify no coherent content in it. He also repeatedly says that the gains from investing in improved software processes are even larger for the 'best organisations', but I couldn't figure out what he meant by 'best' - surely the best organisations are the ones that already have good processes in place, and thus have less room for improvement (absent some weird positive feedback loop, which would result in the best organisations disappearing -ínto a productivity singularity). I can only assume that by 'best' he means 'rotten, but turn-aroundable'.

A few years ago, I bought a house that needed complete renovation before I moved in; i.e. a new water system, new electrics, etc. The infrastructure that brought mains water and electricity to my house was designed and constructed, and is maintained by engineers. The people who connected my sinks and lights to that infrastructure, on the other hand, were 'plumbers' and 'electricians'. The very competent person who coordinated the work was a 'site manager'.

Equally, the people who built and maintain Oracle are engineers. The vast number of people who build software based on it are almost all 'programmers', while the slightly less vast number of people who coordinate them are 'software project managers'.

Me? I'm a programmer, though I do happen to own a novoduplex slide-rule.

Excelente reference book - 2007-12-02
Reviewer Rating:
This is an excellent book for people that want straight facts about the software engineering profession and industry. It is also an excellent source for a plan to understand how to acquire knowledge in search of a better career as a software engineer.

For a long time I tried to find what was the real difference between computer scientists and software engineers because the general knowledge knowadays is that both professions are the same. This book finally gives a clear and straight explanation of the real difference between both.

Another thing I liked a lot about this book is that it refutes the false idea that knowledge in software engineering becomes obsolete too quickly to be useful or to form a body of knowledge.

For all people working in the software industry this is a must-read book to really understand where they should be heading and why.

Not Quite What I Was Expecting - 2007-10-01
Reviewer Rating:
The main focus of this book in on the creation of a professional software development association or organization, similar to the ones of doctors and arquitects. The discussion is interesting, but not very useful if you have to deal with the problems and challenges of the day-to-day life in software development.

McConnell Does it Again - This is the future of our industry - 2006-03-18
Reviewer Rating:
I graduated from a highly specialized program at Virginia Tech that focuses on Engineering Theory - Rocket Science & celestial mechanics (intermediate dynamics), 3 fluid mechanics, etc. with the goal of leading up to Biomechanics concentration. I programmed CAD software and joint-torque analysis physical therapy recommending software as part of my program.

Steve McConnell's association of Software Development to Engineering is a welcome (although at times, not faultlessly backed up) addition to the camp of people like myself who understand firsthand the benefits of Traditional Engineering approaches to Software Development.

Within 4 years of professional experience, I myself was able to secure the top technical position in our industry, Enterprise Architect - one that usually takes 12+ years to even consider.

Do I attribute this to my 152 IQ, impeccable communication skills, or rigorous background in Traditional Engineering? There are lots of people with a VA Tech degree who have high IQs and go through the same communications training. A fundamental flaw I have observed time and time again with my developers is the lack of rigorous problem solving techniques.

When you have spent 2.5 days on a LaPlace Transformation or 6 hours figuring out the angle of an attached pendulum to a moving body in a 3 DOF system in 3D, or deriving acceleration, velocity, and position plots for vibration systems, and you do these things for 4 years straight, often programming to achieve the results, you become a master of elegant problem resolution - engraining into your very being the ability to simplify, breakdown, and attack problems.

My experience in the software industry has proved skeptics like Alan Cooper wrong in my point-of-view. My colleagues and developers are often impressed with my architectures and coding approaches. To me it seems just like second nature - mastering the fundamentals of your technology with a certification, mastering best practices (like Code Complete & CxOne), and mastering inherent problem solving. Then, like the art of Traditional Engineering, there is a beauty to the approach you choose in the art of software design.

Yes. The leaders that will take this industry forward are at NASA and BOEING and increasingly Microsoft. We are Software ENGINEERS, and must embrace that distinction to move forward as a honed, veritable practice in general. Steve McConnell has a good jump start on telling you why - but don't expect an indisputable and flawless argument.

Browse Similar Topics

Top Level Categories:
Software Engineering

Sub-Categories:
Software Engineering > Management