Quality is hard to define, and I don't know of any satisfactory description (much like architecture). In Zen and The Art of Motorcycle Maintenance, the narrator (Pirsig) spends a great deal to time trying to define quality, which eventually drove him insane (requiring shock therapy).

One way you can define quality might be how close the item comes to ideal, when viewed through different perspectives.

For example, for a software project, we can look at quality from the perspective of the end user - does the application work? How easy is it to use?

We can look at code quality - How complex is the code? How much of the complexity …

This book reflects my attitude towards building software, and is now one of my favourite development books (The Pragmatic Programmer being my all time favourite).

The only thing I don't really agree with is the emphasis on XP practices, notably TDD. I think professional developers should know about TDD and have practiced it, but I don't think it's a requirement to being a software craftsman. The debate between Jim Coplien and Uncle Bob on TDD is good food for thought.