The perils of impulse buying from the internet without carefully reading the precis! I had expected this to be an examination of professional practise, with the emphasis on people working in the software development profession. What it actually is instead, is an introduction to the wider aspects of development and professional activity primarily focused on (young) people who have maybe done some coding, but haven't (yet) experienced all the other disciplines that surround the actual cranking out of code.
So, leaving aside my misconceptions, how does it achieve that goal? Well, on the one hand, it does a reasonable job of providing an overview of the other aspects of the SDLC like project management, architecture and testing, and different development methodologies. It goes into enough depth of most to give a decent introduction to the subject, mostly without drowning the reader new to those areas - it gives code examples of some areas (eg OOAD) where this makes some sense to do so and reflects on the presumed target audience's background as coders, and provides plenty of good references throughout. Actually, it's at its best in the chapters which centre around the design, development and, to some extent, testing of code.
So far, so good. Unfortunately, it is rather uneven in quality and focus, and my overriding feeling when I got to the end was that the author had taken his experience and generalised that out to be The Way Things Are Done. So software is developed in Software Development Organisations (no software development inside non-software companies?), every software development ends up with a detailed code inspection (really? even in Agile developments? even in really small teams?) and generally the content is a mix of well-described theory but with some real problems when it goes into detail.
For example, his first descripton of abstraction as "Abstraction means being lazy. You put off what you need to do by pushing it higher in the design hierarchy" - I can understand what he is trying to say here, and in context of the OOAD content later it would almost make sense, but appearing much earlier in the book, in the chapter on design principles it is very misleading.
Another example is his treatment of Use Cases, which were horribly badly explained, with supposed UCs that conflated multiple use-cases into a single item which would lead to a terrible design.
There are several other examples I could give, but my other bugbear is the tone of the writing. Most of the time it's comfortable and professional, but occasionally he drops into this over-conversational style as though he's suddenly realised the age of the target audience and wants to speak to them in their own language, and makes an excellent job of it. Not. (In conscious parody of his style there, I hasten to add). And it just seems so false, and so out of keeping, like your uncle suddenly trying to breakdance at a wedding.
It's a shame, because it's nearly a good book, but it's too uneven, too conversational in style in places, and needs (oh what irony!) a really detailed technical review to fix the bits which are misleading or just wrong.