You can&#x27;t really define what quality software is, though. You could have a patched together backend that &quot;just works&quot; and has a great UI that customers love, but how is that &quot;quality&quot; software? The software end of it is clunky and patched.<p>On the other hand, you can have completely documented, easy to read, well thought-out code that has a terrible UI that no one will bother using. I guess you can say the software is &quot;quality,&quot; but it doesn&#x27;t matter.<p>Then again, maybe &quot;quality&quot; software to you is software that works, like the first example. In that case, it doesn&#x27;t matter how well documented it is. It works. It&#x27;s self-readable at least to those who wrote it. Maybe the team will never grow beyond that, so who cares? Or by the time it does, it will be rewritten anyway for other reasons.<p>The point, I think, the author is trying to make is that quality means so many things it means nothing. It&#x27;s a useless term because it has no objective meaning. We can argue about what you think quality is and what I think it is, but it&#x27;s likely going to be different for any two people.