Judging the quality of software
time to read 2 min | 278 words

I found myself having some interesting discussions about quality, complexity and how to judge them.
More to the point, the difference between quality and fitness to use has came up.
My answer about judging quality was that I can judge that by applying generic software principals, which I have outlined here and by working with the software and seeing if it makes sense.
Make sense is hard to define easily. It is partly that the software is written in an understandable way, easy to work with, follow design guidelines and best practices and similar things.
My litmus test for that is the ability to go into a piece of software, and after a day or two (assuming that I understand the domain, of course), being able to work with the software.
I might not like it very much, but I will be able to work with it.
Trying the same with poorly written software doesn't really work, there is nothing to really grok there, and memorization and cursing is often your only alternative.


Subversion is a really amazing piece of software, I am working with it extensively, mostly by reverse engineering things, and
I keep throwing invalid input, at which point it:
  • Errors
  • Gracefully
  • With a reasonable error message
  • That makes sense
Compared that to other systems that I have worked (and working with), that may give your the following information: Error

In general, if I go WTF more than two or three times while reviewing how I work with something, that is a very bad sign.
Tweet Share Share 2 comments
Tags: