Log in

No account? Create an account
To The Side

Software Quality

Lots of people say that they have a high standard of software quality. What exactly they mean is only rarely defined, though.

To me, and probably to most professional engineers, a "high standard of software quality" usually makes me think that the program has the following aspects about its code:

* Easily readable.
* Consistent.
* Well-organized.

And that's really it. If it has all those things, in my mind it's quality software. And if it doesn't, it isn't.

I know, that sounds ridiculous, because obviously what should be more important is the interface or something, right?

Well, let me tell you, given enough time, the interface of poor-quality software will degrade into un-usability, or the program itself will have so many bugs as to be unreliable. That's just the nature of unreadable, inconsistent, poorly-organized code. The effort to modify each little piece is like a linear function as time goes on, meaning that the amount of time required to add a new feature or fix a bug could be graphed as an exponential (or really, parabolic, I suppose) function, probably.

I have spent too much of my life fixing the software of people who can't think of a future beyond the next few seconds. HELLO EVERYBODY. PROGRAMMING-TYPE-PEOPLE: Have you ever thought about the fact that "saving time" now with poor design is going to eventually cost you so much time that your program will become unmanageable and you'll want to start over from scratch? Or just give up?

It's like the criminal mentality of "Oh, other people get caught, but I won't." It's like, "Oh, other people's software becomes unmaintainable, but mine won't."



My mom really couldn't give a crap what any programs code looks like.
Of course not.

avatraxiom: ...given enough time, the interface of poor-quality software will degrade into un-usability, or the program itself will have so many bugs as to be unreliable.

That's something users do care about.



Yet wordpress lives on with bad code, many bugs and great interface, there is a link between bad code and bugs but not with the user interface. You can have bad buggy code with a good interface and good clean code with a bad interface.
Yes, I understand this perception.

Wordpress is not that old. In any software project, you can get away with writing bad code for a few years. But eventually it will catch up with you.


Geek out

Bad code gives us geeks something to do ;)

"We'd love any opportunity to geek out and rewrite everything in the newest, sexiest possible language." - Coding Horror

Re: Geek out

Hahahahaha. :-D That is kind of fun, true. :-)



A software project at that state is sort of like a mixed-color glob of silly-putty. Managers will give orders to work on the code, but the materials of red, blue, yellow, green, are just rushed together and tacked onto, into and through the ball.

Yeah, that's a good analogy. :-)


wo + r + c != q

So... You'd consider well-organized, readable code that was consistently the most complex solution available to be quality software?

I think your list is good, but a bit short for a list of requirements of quality software. In my mind, if you're not addressing complexity, you're not addressing quality.

Re: wo + r + c != q

You make a very good point. It is in fact a point to which I have devoted an entire book that I'm writing. :-)

However, in this instance I would say that was overly complex software with good code quality. But yes, probably not quality software. :-)

There's a post very far back in my blog about simplicity--that's the centerpiece of my book.



A long, long time ago in a very small village on the outskirts of civilization a men fell down a cliff. He was hanging from a small tree that was slowly tearing loose from the wall it had grown out of. The other villagers heard his screams and rushed to his rescue, but all the ropes in the village combined weren't long enough to reach the man so the villagers rushed to the rope-maker and asked him make the extra rope needed to reach the man.

The twiner was however a very proud man and he replied that he was doubtful he could save the man, since the twiner always delivered excellent quality rope. He normally took three hours for every meter of rope and there were 10 meters needed, so he informed the villagers that it would take him thirty hours to build the rope, but that he would do his best to work faster.

While the twiner was creating these 10 meters the fallen man was holding on to the branch in fear of his life. At the dawn of the next day the twiner had finished the 10 meters and in 24 hours he had created 10 meters of beautiful rope that was a delight to look at and was hand-crafted with great precision.

Proudly he headed towards the cliff, added the rope to the other pieces of ropes and looked down where he saw his fellow villagers burying the fallen man.
Yes, but the man shouldn't have fallen down the cliff in the first place.

Sometimes disastrous things happen, or people make stupid mistakes (like falling off a cliff), and then you have to deliver something in a hurry that's no good, technically, but does the job.

But that doesn't mean it was a good rope, it just means that it did what it was supposed to do. If the man produced poor-quality ropes every day for the rest of his life, he'd be having a hard time keeping his business alive far into the future.

You should also read my latest post where I address a part of the point that you're making.

There was also a second village where the rope maker never thought about tomorrow. When a man in this village fell off a cliff the rope maker didn't hesitate to start on the extra rope.
He only ever made rope when someone needed it right at that moment. He could make rope faster than any other rope maker the village had ever known, but it also tended to wear out after a few weeks use.
His extra length was joined to the other lengths of rope and lowered to the man. It looked like for a few seconds that it would hold, but then one of the length a few weeks old began to give way. The fallen man was to far from the tree to grab it again and fell to his death.

Neither extreme works. I will admit to having been on both ends of the spectrum at some point in my life as a programmer. (If I and others that I have known, who had the the first rope makers mindset, are any guide he would have insisted that he be given a week to make the full rope because knots can slip.) If you don't break free of the "we need it yesterday" mindset more often than you allow it, and once in a while stop to replace bad rope with good, more likely than not you might find it is you on the bottom end of the rope in a scene reminiscent of Loony Toons with the rope breaking strand by strand.
This is a really good response. :-) Thank you. :-)

I think well organized code is not an indicator of good quality software. Good coding is important for us - coders. Users don't care about your code, they need usability and functionality.