Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

I'm very very guilty of this myself, so while I am getting up on my high horse, I am by no means an innocent. It's also in no way perl specific, though I am going to focus on software in general, largely since I haven't a clue how to identify a high quality wine or batch of cement.

In my reading and working and perusing of things I see a lot of attention being paid to "quality" of the software.

  • "We write high quality software."
  • "Our software is of the highest quality."
  • "This is the best quality wine you can buy."
  • "Our product quality is unsurpassed."

But what the hell does that mean and how do you prove it? Think fast now - you march around telling the world that your software is top notch quality. You're an awesome programmer and you write the best stuff. And my response? "Prove it."

If you're lucky, you can point to your comprehensive test suite. You've written thousands of tests and it exercises every point in your code. Both values for every conditional, every while loop, every function/module/class/you name it. It's created/modified/set/unset/deallocated and it all goes off clean as a whistle.

You produce your impressive Devel::Cover charts and graphs and have green 100%s across the board. Everything's documented, everything's tested, everything works (at least, as far as your test cases are concerned). You have demonstrated that your software is high quality.

Haven't you?

Well, you're off to a good start. You can demonstrate that your software pretty reasonably behaves with a huge amount of sample input. Basically, that it works. Sure, there's always the case that the user types in something that you really weren't expecting and things go haywire, but you should've handled enough cases to be reasonably sure you're fine. You've quantified the quality of your software.

Have you? Microsoft's software normally works, but I tend to consider it low quality.

If you don't have a test suite, then my suspicion of your software will grow with its size. No test suite and a 100 line program? Yeah, it's reasonable to assume that it works fine (assuming your reputation is good enough) and that you tested and caught the bugs. No test suite and a 100 module program? I'm a little more dubious that you've caught ever possible option. It's also easy to assume that you can introduce bugs as things get worked on.

You stomp your little feet and scream that it's good quality and I shrug and again ask you to prove it.

So then you start showing me pieces of the code. Carefully handcrafted and elegant and efficient in what they do (you claim). Sure, this can demonstrate the quality of your work, but only to another skilled craftsman. And, frankly, when it comes to software, another skilled craftsman is probably going to want to at least know that there is a reasonable test suite, even if he's not inspecting it.

But let's assume we're past the test suite. Now what? Let's break it down into 4 simple cases.

  1. You have good quality software and I can recognize it as good.

    Congratulations! You win. You demonstrate your fine craftsmanship to me, I immediately recognize you as one of the great masters and at a minimum continue to evaluate your software, if not outright choose it.

    For this approach to work, you not only have to be truly capable of producing great work, but you need to find someone capable of recognizing it. It can work, but if this is the way you demonstrate quality, you've greatly reduced your market. A Rolls Royce may be hand-crafted elegance and worthy of the cost, but most of the public probably doesn't know why. They needed some other authority to tell them it's better, an expert in the material.

  2. You have good quality software and I can't recognize it as good.

    You're hosed. You can't quantify your quality, and I (for whatever reason) can't recognize it. Sure, it's possible that you'll convince me that you're right and I'm wrong and it's really good software, but I've probably already made up my mind. I'll go off to choose a different product that I think is higher quality (maybe they have a full test suite), regardless of whether it actually is or not.

  3. You have poor quality software and I can recognize it as poor.

    You're hosed. Despite all of your stomping and hooting and folderol I know you're full of baloney and you've lost my business. With no test suite, you can't demonstrate that it actually works, so you're relying upon my looking at your software and assuming that it must work, based upon what I've seen. But it looks crummy, so I'm going to assume it doesn't work. On to the next product.

  4. You have poor quality software and I cannot recognize it as poor.

    This is a very dangerous place to be in. You'll present shit and I'll call it shinola and buy 1,000 gross of it and I'm off to the races. Later I may or may not realize that there are problems and may or may not complain about it. You may keep my business, you may not.

    But you're targetting people that don't know any better. Don't get me wrong, there's a large audience out there, but it's an ever dwindling one. It's relatively easy to get smart and relatively hard to get stupid. Once you've learned that you don't put your hand into a campfire, you rarely forget and start doing it again.

    So you're basically hoping that I never begin to think that your software is low quality (and, remember, for this example we're assuming it is), because once I make the connection, I'm off to another vendor. Admittedly, they may also be poor quality (again, in this example I'm a poor judge), but the point is it's no longer you I'm doing business with.

In 1 out of the 4 cases, you're fine. In 2 you're boned from the getgo. In 1 you're probably boned in the future. That's a 75% failure rate, but you actually had good quality software 50% of the time. Your good stuff will fail in the marketplace more often than it will succeed, even if it's good "quality" (which you can't quantifiably demonstrate.

Now what? Well, you can go back to your software and write up a comprehensive test suite and probably find a few bugs in the process and quash them. Then you've got your test suite and you can quantify your quality. But the underlying code may still be junk, just very functional junk. So, I ask you, is that high quality software or not?

The case can be made that "good quality" software only need a few elements.

  • Demonstrably does what it's supposed to do.
  • Is "easy" to maintain and develop. ("easy", of course, is a relative term)

And then what more do you need? You can prove your software works to the Doubting Thomas, and he can even look at your code and understand it after the fact (if need be). More importantly, the next developer you hire can look at it and understand it. Since your software is high quality, hopefully you'll only hire other progarammers who product high quality software and can also recognize high quality software. And everyone is happy.

But I still don't feel like this is enough. Every time I hear the word, I picture Dilbert's boss saying, "And we'll get a big banner that says 'quality'." It's a meaningless, undefinable, useless word that everyone tosses about like it's the holy grail. But when pressed on the issue, they can't explain why their software is high quality. Just because it took a long time to complete doesn't mean that it's any good. I could take a long long time building a new automobile and it'd still suck.

Isn't it silly to claim that your software is something that you can't even define or demonstrate? How do you know that your software is very high quality? You might as well start saying that your software is all very gloomf. I think that's what I'll do.


In reply to What is quality? by jimt

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2024-04-16 11:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found