Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers | 
 enlarge | Author: Steve Mcconnell
Publisher: Addison-Wesley Professional
Category: Book
List Price: $44.99
Buy New: $14.55
You Save: $30.44 (68%)
New (20) Used (17) from $9.12
Avg. Customer Rating:  22 reviews
Sales Rank: 392853
Media: Paperback
Number Of Items: 1
Pages: 272
Shipping Weight (lbs): 1.2
Dimensions (in): 9.1 x 6.9 x 0.7
ISBN: 0321193679
Dewey Decimal Number: 005.1
UPC: 785342193671
EAN: 9780321193674
ASIN: 0321193679
Publication Date: July 10, 2003
Availability: Usually ships in 1-2 business days
Shipping: Expedited shipping available
Shipping: International shipping available
Condition: Hello, Thank you for reading, I am a new seller, My name is Victoria, all books are in stock and will ship out right away. I look forward to earning your 5 stars. I answer all emails within the hour if you have any questions about anything I sell. Thank you for giving me a chance to earn your sale. please note certain older titles may have publishers mark and/or light shelf wear. Please choose EXPEDITED shipping to receive book faster! Standard shipping is between 4-14 days!
|
| Similar Items:
|
| Customer Reviews: Read 17 more reviews...
 Excelente reference book December 2, 2007
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 October 1, 2007
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.
 middle brow May 17, 2007
1 out of 3 found this review helpful
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 into 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.
McConnell Does it Again - This is the future of our industry March 18, 2006
0 out of 75 found this review helpful
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.
High Hopes for Practical Solutions, Dashed on the Rocks of Pet Theories February 9, 2006
10 out of 12 found this review helpful
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.'
|
|
|
