The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

What's the Most Professional Way to Represent This?

I'm working on some software that utilizes a database that the user can access.  One of the fields represents the number of occurrences of X.  However, there have been an undetermined errors in the production of X in the past.  Yet, I want to show something in the number field, even if it's an asterisk or "unknown" or something along those lines.  Here's a representation of what I'm talking about:

Product            # Manufactured
------------        ---------------
Widget(OK)          ???
Widget(error)        ???
-------------      --------------
Total Widgets        10,000
Bret Helm Send private email
Monday, August 14, 2006
 
 
An odd request indeed. I would have gone for just:

Total Widgets (incl. errors) = 10000

But if you're trying to leave placeholders for when you have some actual figures, then just use "Unknown" rather than "????"

I'd love to know the context....
Documentation Doctor Send private email
Monday, August 14, 2006
 
 
n/a could also be used.
Matthias
Monday, August 14, 2006
 
 
I would vote with the Documentation Doctor. You are adding clutter without information here.
George Jansen Send private email
Monday, August 14, 2006
 
 
Are you asking on how to represent this in the database ??

I assume you want to track products in the DB that have had failures in manufacturing so you have some kind of history about certain products why dont you use 0 or -1 to indicate failure ?

I would personally have a seperate products table

productId description
0        widget

then a manufacturing table

product id  amountmanufactured
0          10000
0          -1  ---- indicates a failure
mocksy Send private email
Monday, August 14, 2006
 
 
"I'm working on some software that utilizes a database that the user can access."

That's the first issue. Sorry.

select count(widgetid) as 'Widget(OK)'
from widgettable
where widgetid IS NOT NULL

select count(widgetid) as 'Widget(error)'
from widgettable
where widgetid IS NULL

Note that the handling of a null in a database is really, really dependent on the database and it's ANSI settings.
D in PHX Send private email
Monday, August 14, 2006
 
 
You're trying to stuff two different data types into one field, which causes the confusion.

When you measure X, there are two things that need to be tracked about the measurement.

1. Were you able to get a reliable measurement of X?
2. If so, what was that measurement?

Or, maybe the count is good, but the widgets might not be.  In that case, you're measuring:

1. How many widgets were prepared?
2. How many of those widgets are known to be OK?  (Or, perhaps, known to be bad)

If you're doing statistical quality control & process management, you really need more fields.

1. How many widgets were prepared?
2. How many were tested?
3. Of those tested, how many were proven OK?
4. Of those tested, how many were proven bad?
5. Of those tested, how many tests were inconclusive?

etc.

This is really a problem with the business analysis, not the technical implementation.  It's not clear what exactly the database should track, therefore it's not clear how to design the database.  I'd go back to the subject matter expert and get this cleared up in the business requirements.  If I was the business expert, I'd rewrite the spec if I understood what I was doing.  Or I'd reread Deming if I didn't understand what I was doing. :-)
Flow
Monday, August 14, 2006
 
 
+1 to Flow.

In addition to how many were proven good, bad or inclusive, it would be nice to know how many false positives and false negatives were encountered. A high number of these may indicate a problem with the testing methodology or tools, rather than the widgets themselves.

But if you're just making a list of valid widgets per month and a list of defective widgets per month, then its less ambiguous from a programming perspective to record the total and the number valid, then find the difference when you run the monthly report.
TheDavid
Monday, August 14, 2006
 
 
Thanks for all the responses!  I think I now know which direction I need to head.
Bret Helm Send private email
Monday, August 14, 2006
 
 
There's a book I read many moons ago when I was getting started.  Readable & generally reliable information.  This link is to the second edition (i hve the 1st)

http://www.amazon.com/gp/product/0201752840/sr=8-1/qid=1155588493/ref=pd_bbs_1/102-0194189-6881771?ie=UTF8
a former big-fiver Send private email
Monday, August 14, 2006
 
 
Sigma? If I remember correctly, it's the square of the average deviation. It's where the term "Six Sigma" comes from - I.e. no errors within six standard deviations.
[x]
Monday, August 14, 2006
 
 
Errr... except that only works when each item deviates by a range, not a binary yes/no.
[x]
Monday, August 14, 2006
 
 
Oh, nevemrind. Rereading I see that you might be going for an average deviation (per month, for example), in which case it would work. It depends on how long you've been tracking defects. If you've been tracking them for a while, you can generate a pretty solid sigma (your 95% confidence level will be a small rage).

If you have very few defect levels tracked, then you're basically flying blind anyway, you can generate a sigma, but your 95% confidence level will be shot to hell.

You'll have to look up how to calculate this stuff from the given data (I forget how you calculate the 95% confidence level... the square root of something over (n-trials) or something...), but standard deviations, sigma, 95% confidence levels (or x% confidence levels) are all pretty standard and IMHO probably the most professional way to present this stuff.
[x]
Monday, August 14, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz