 |
Java. Quality. Metrics (part3)
Posted by cos on October 21, 2005 at 11:34 PM | Comments (3)
Hello everyone!
I'm writing this sitting in Lufthansa's 747 – boy, I've seeing better planes in my life – going towards Frankfurt. There I will change planes and fly for another two and a half hours to Saint-Petersburg, Russia. There I'll have a lecture at the Saint-Petersburg State University. And guess what would this lecture be about? Right, it's about Java quality again :-) (I'll write about this event as soon as I'll be flying back two weeks later). And I have to say that electronic technology is great and it's advancing much faster than all these last century's wonders like airplanes and stuff. Could you imagine that my 15” laptop doesn't fit between seats? I have to type these things sitting in a really awkward position :-( (I wish I'd have one of those tiny yet cool X40). And at the same time I'm online! Wow!
Speaking of quality: sitting here I got an idea, that a “quality” isn't about something good for anyone. It's more about a reasonably acceptable level of things and services. It's like these two entries in a flight's menu and both are “reasonably” good. (Well, I guess it, because I didn't dare to taste a chicken :-( ).
Perhaps, someone's flying in the first class and having caviar right this moment. But when I realize how much they are paying for this quality I start thinking that I'd rather be a reasonably cheap passenger, accepting a reasonable quality of public air transportation.
Did you start wondering what I'm up to? Well, I'm about software testing again.
Let's see: are your bosses willing to pay for finding all the bugs in software packages your company's making? Really? Well, then you're working at Microsoft and your QA department's budget is really fat (although, it is not helping much, isn't? :-) As rest of us are leaving real lives, more or less, we have to balance the cost of hunting bugs down and their harm to our business. No, really, don't consider me too radical or cynic. Let's just be real.
Will a bug in one of those debugging modules hurt much of your business and relations with customers? Naah, I don't think so. Will a dump typo in a help messages make a lot of troubles? Probably not. But what would you client think about it when noticed? They might not tell you, but I can say this. It'd be something like this “Hmm, what are other bugs this POS (piece of software :-)) has that are not that harmless and obvious? Shall I invest into this platform any more”? Then merely imagine all perturbs of discovering and writing tests for this debugging module's bug and simplicity of killing the bug of help messages? You got the point, right?
Of course, I'm intentionally simplifying the picture. It might not be that easy to prioritize one bug over another. So, let's discuss a few techniques you might find helpful in making such a decision. Of course, they are pretty much empirical and you'll have to decide how confident you are about them.
- Firstly, it is source code's prioritization by their scope of visibility. So, it says that a private code is unlikely to have much effect over what is seeing by customers. And, likewise, public method is more likely to affect some important functionality. Well, arguable, but it might be a fair-enough starting point. Especially in libraries writing business.
Actually, this is what unit testing is about, I believe. Due to the nature of unit testing approach (for Java at least) it is focusing on public methods testing. And if you ever want to test a private method – hello, isn't it time to change its scope of visibility and make it public? As you can realize this technique has its benefits and shortcomings
- Secondly... Hey, wait. We're approaching a landing site and they asked to turn off any electronic equipment. Since I want to land safely and the battery is drying anyway, I'll post that small article now and will continue this interesting topic afterwards
Kinda hint: Deutsche bier – this is what I call a reasonably great quality :-)
Auf Wiedersehen,
Cos
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Cos,
I hear you on Boeing 747 configuration for Lufthansa. It is nice that they offer internet access. To bad that it's not usable for anyone carrying a normal sized laptop. In fact the seats are so tightly packed that it's not even comfortable to read a book!
Good luck with the seminars.
Don't these little annoyances (bugs) build up until they completely degrade the users experiece?
Posted by: kcpeppe on October 24, 2005 at 12:16 AM
-
Well, they might. I'm about little bugs, not 747 :-) The matter of fact, that you have to balance bugs importance not only from product quality's point of view, but also from UE (usability and ergonomics) one
Posted by: cos on October 24, 2005 at 12:41 AM
-
So there is another interesting question: Is it possible to write bug free software? And practically all programmers say "no, of course not".
But then you look at NASA. Let's say they have one bug per 100k lines of code (I number I seem to remember hearing somewhere. So okay, most programmers quibble about the 100k, but concede that okay, something like that.
Then we say, okay, well what if you have two NASA programs, each with 50k lines of code. This means that on average one of them has one bug, and the other is bug free. Viola! A bug free program.
But now most programmers try to insist that both the 50k program must have bugs, maybe they just haven't found it yet. So you half the size of the program again and again and again... and each time there 'must' be a bug.
Until we get down to a one line program... so the question is, is it possible to write a single line of code that is bug free? And here is where I think it comes unstuck, because I think that most programmers (at least the ones I have talked to), will admit that yes, it should be possible to write a single line of code that has no bugs (even if it is just System.out.println("Hello World"); or int i = 10;).
So therefore, we have shown (by reductio ad absurdum) that it should be possible to write a whole program that is without bugs. The common concept that every program *must* have a bug is wrong. But it is surprising how much moost programmers will fight to hold onto that concept... why? Because it gives them an excuse, and it allows them to dodge responsibility. It allows them to shrug their shoulders and say 'ah, well, every program must have a bug, it is not my fault'.
Thank goodness the engineers who build planes and bridges do not have that same attitude!
Posted by: rickcarson on October 24, 2005 at 11:00 PM
|
java.net RSS Feeds
