How do you measure security? The number of buffer overflows is not a
measure of security.
Good question. ?Just look at the “Is IE or Firefox more secure” debates.
But do you mean to say, with a question like that, that security isn’t
important because it can’t be easily quantified?
Nope, I’m saying that unless you can quantify it and measure it you
can’t claim to have it.
Functionality: ?This one’s obvious. ?A program’s no good unless
it does something useful.
Compliance with the specification. This is a useful measure. If code
doesn’t comply with the specification it has no value. BTW, this is an
either or, their is not better or worse when it comes to complying
with the specification.
Only if the spec is right. ?Your statement is only valid if the
customer actually knows what they want.
If the customer doesn’t know what they want it is your job to guide
them to learn what they want. It is not your job to decide what they
want for them.
User-friendliness: this one’s related to functionality. ?If a program
does something useful but the end-user can’t figure out how,
or the process of doing it is complicated and unintuitive, it’s of
no use to them, especially if there’s a competing product that
does it more easily.
Yep, with a focus groups and good use of prototypes you can measure
the usability of a GUI. I have never met a programmer (including
myself) who was qualified to judge usability.
Focus groups? ?snort Didn’t Microsoft produce the original Xbox
controller–you know, the one that wouldn’t fit well into the hand of
anyone smaller than a gorilla?–because some focus group liked it?
Focus groups are among the worst ways to produce good usability.
(Hollywood’s use of the practice makes for lousy movie QC too.)
You get good usability by 1) dogfooding and 2) beta tests with
actual people who are going to use the product.
MS is the perfect example of a company that has never ever made
effective use of basic human factors principles.
Efficiency: This is particularly important in game programming.
All other things being equal, would you rather play a game where
the levels take a minute to load, or where they load in 5 seconds?
And on a smaller time-scale, the less CPU time each individual
operation takes, the more you can fit into a frame that only lasts,
X number of miliseconds, allowing you to boost your framerate,
improve graphics or gameplay quality, or both.
In that example the word “efficiency” has no meaning.
What you are really talking about is not efficiency, but just another
example of complying to specifications. If the specification says that
you will achieve 60 frames/second then meeting that specification is a
requirement. IF you don’t meet it, you have 0 value. OTOH exceeding it
is a waste of money and therefore is not an inefficient use of the
Again, this is assuming that the spec is right.
If the spec is wrong, or incomplete, you need to point that out and do
your best to make sure the spec is complete and that the customer
believes it is right.
fundamentally, that it’s complete! ?60 FPS on what hardware
configuration?) ?Specs don’t magically make for good programs.
They help quite a bit, but they’re not code and can’t substitute for
it. ?(See http://www.joelonsoftware.com/items/2007/12/03.html for
the problem with thinking this way.)
I like Joel, but you can’t use him as a authority in one area while
refusing to accept him in others. He is a huge fan of LISP, the
original (more than 50 years and going strong) managed code
environment. BTW, Joel is the boss. He gets to write and change the
specs. He writes from the point of view of the responsible party. You,
the programmer, are rarely the responsible party. You get to suggest,
request, and even through a tantrum. You do not get to make the final
Also, your assertion that if you don’t meet it you have 0 value seems
a bit strange to me, as does the statement that going beyond it is
Are you saying that if you only get 59 FPS then your code
has no intrinsic value?
If the spec says 60, the 59 doesn’t cut it.
Anecdote time: The team I was on at E&S built what was at the time the
fastest graphics box ever. (it was not as fast as a $15 card you find
in a box at Goodwill today…) Chrysler put up $30 million to help
develop the box. If the box was late, or it lacked any of the required
features, E&S would have to give back the $30 million. E&S was making
about $120 million a year back then. If they had to give back the
money the company would close. Two months before the end of the
contract the lawyers from E&S and Chrysler sat down with the VP of
engineering and the President of the division and went over the box
and ran tests and demos to demonstrate that every feature was there.
They found one that wasn’t. It had been left out of spec. We had 1
month to design, implement, and fully test the ability to do color
overlay planes using our hardware and X11. The trouble was that we had
no overlay planes. We did it. Blood was not shed, though tears were. I
did get a whole box of marker pens thrown at me one…at…a…time.
That is a case where not meeting the specs had a value of a negative
$30 million dollars. That is how business really works. Programming
has to work within business. Saying that not meeting the spec gives
you code with $0 value is being very nice.
?Also, is there no value in producing code that’s
capable of 70 FPS on the specified hardware, thus allowing you to
lower your minimum system requirements and make your game
available to more potential buyers?
If you got to 70 without affecting budget and schedule, who is going
to complain? That is found money. If getting there cost anything more
than getting to 60, then yes, it was a mistake to go there. If not
going past 60 could have save a day on schedule, then going to 70 is a
This seems to be a fundamental philosophical difference.
Yep. I base my view on having brought in a number of projects on time
and on budget.
to measure quality by numbers and things that can be tested,
specified and proven. ?I prefer "will people enjoy using this?"
and if not, “how can I make it work better?” ?Completely
subjective, impossible to prove, but it’s been very
successful for me as a design and implementation guideline.
I’ve occasionally gone out on my own initiative and done
something the spec didn’t mention because I’d like it
better that way if I was the one using the program. ?Most
of the time when I do that, the boss ends up having the
spec altered to match my work.
You finally got it. When you see that the spec is wrong or that it can
be improved you change the spec. You do it after you have cleared it
with the customer, whomever that may be.
The boss has a budget and a schedule to manage not to mention having
to manage customer expectations. If the programmer decides to go off
on his own and make changes that effect any of those he needs to be
talked to. The second time he needs to be fired. And yes, I have fired
a lead developer who did everything you describe and created a great
game. Trouble is that it was 4 months late because of what he did.
That caused us to miss the Christmas market.
Bob PendletonOn Wed, Jun 10, 2009 at 5:45 PM, Mason Wheeler wrote:
----- Original Message ----
From: Bob Pendleton <@Bob_Pendleton>
Subject: Re: [SDL] [OT] Dao language 1.0.1 with SDL and OpenGL bindings
SDL mailing list
SDL at lists.libsdl.org