Steve McConnell,the author of this book, owns a software engineering firm called Construx. The book contains his ideas on how software engineering should be handled. McConnell feels that traditional Computer Science degrees ill prepare students for jobs as software engineers. He advocates a course of study for programmers that mirrors the educational path of mechanical engineers. McConnell points out that most areas of engineering did not require a license until the things they made started breaking and killing people. He points to the large number of bridges the collapsed in the early 1900's and a boiler explosion at a school in Texas the killed 300 children as examples.
The book is directed toward the managers and employers of engineers rather than software engineers themselves. The discussion of the professional development process at Construx is very interesting and I believe it could serve as a model for professional development in a variety of areas. Construx breaks the core competencies needed to be productive as a programmer into about 10 different areas of:
each area has a well defined progression through four levels:
At Construx each programmer's pay is determined by how much far they have advanced toward the higher levels in each of the areas of expertise. everyone knows exactly how much their coworkers make and they know exactly what they need to do personally to get to the next level of pay. The requirements are high, so everyone always has room to grow and improve.
McConnell Does it Again - This is the future of our industry
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
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.'
Excellent overview of software development
My biggest disappointment is the lack of details and specific examples. It's like McConnell tries to be vague to avoid spending time on tedious fact finding or in depth analysis. This book provides an overview of software development that will benefit anyone in the industry.