Re: number of bugs
Re: number of bugs
- Subject: Re: number of bugs
- From: Brent Gulanowski <email@hidden>
- Date: Sun, 26 Oct 2003 18:56:55 -0500
On Sunday, October 26, 2003, at 06:09 PM, Darrin Cardani wrote:
At 1:54 PM -0800 10/26/03, Brent Gulanowski <email@hidden> wrote:
On Sunday, October 26, 2003, at 03:09 PM, Chris Hanson wrote:
> Experienced programmers know that every line of code is an
opportunity
> for more bugs, and prefer to minimize the amount of unnecessary
code
> to accomplish a particular task.
I'm sorry but that is specious, since writing less code is an
attribute
of OOP itself, if you use it right.
There is hard evidence which shows that Chris is right. For example,
"Program Quality and Programmer Productivity" by Capers Jones lists
the results of a study which showed the following error rates as the
number of lines of code increased:
Proj. Size Error density
---------- -------------
< 2k loc 0-25 errors per kloc (1,000 lines of code)
2k-16k loc 0-40 errors per kloc
16-64k loc 0.5-50 errors per kloc
64k-512k loc 2-70 errors per kloc
512k loc 4-100 errors per kloc
Clearly there is a correlation between the amount of code written and
the number of errors per line of code.
I did not say he was wrong. It is not relevant to what he is arguing.
If he or someone else did the same thing, it would satisfy the same
constraint. Others have pointed out the circumstantial evidence that
Apple is rich (or otherwise a special case) and therefore should
produce better code and test better, but there is not necessarily any
correlation there, either.
What you are really saying is that it saves lazy programmers the work
of doing their own software engineering.
It saves good programmers from having to do engineering that's already
been done, and that they might do wrong, too. (Just because they're
good doesn't mean they'll do everything perfectly! How many times have
you found the source of a bug and slapped your forehead and thought,
"I can't believe I made that same mistake again!"?) That frees them up
to do new engineering that hasn't been done, which results in a better
product for the same cost, or an equally good product for less cost.
The sum total argument here is "better Apple do it than I do it" --
ostensibly because they will necessarily do a better job, but possibly
for less positive reasons. There is nothing stopping an individual
developer from doing the same design work Apple did, other than time
and money, but as we have already agreed that not re-writing the same
code over and over saves time and money, why is Apple the only company
we expect to do the design work involved in avoiding re-writing code
over and over? Because they are rich or because they run the operating
system or because it is just assumed they will do it better because
they are Apple?
As for whether programmers are supposed to be lazy, the readership have
successfully demonstrated the problem with using a derogatory word in a
new, positive light -- it is good market-speak, but it obfuscates
language. "Lazy" does not mean doing less total work to the benefit of
all (despite contradictory usage to the contrary), it means avoiding
doing a job right the first time and having to do it over again later,
or, worse, in hopes that someone else will do it for you. Efficiency,
including designing code to be re-usable, means doing research and
thinking about the problem, which is not a common component of laziness.
Again, there is this implicit assumption that the developers at Apple
are somehow better than other developers. I will accept that if you
mean other developers who are hobbyists or who do not write software
like their lives depended on it, but I should expect that the
professional devs on this list are up to Apple's par, and that
therefore they can do the same quality of work that Apple engineers
can, all things considered.
On the other hand, if you assume that Apple will do a better job
because of some kind of insight into the frameworks, as their owner and
maintainer, then you are making a completely different observation than
you claim -- you are saying that it is not enough to know the API to
build good extensions to it, in which case, the frameworks are in need
of re-working.
My only important point is that the attitude of waiting for Apple to do
something is possibly not a good. Even if there are practical reasons
to leave it up to Apple, I don't know that it makes it better to do so,
just understandable.
On Sunday, October 26, 2003, at 04:04 PM, Shaun Wexler wrote:
Patience, guys. There have been mostly NEGATIVE opinions posted so
far about the "new" controller layer and bindings facilities in
Panther, which is to be expected, both from those who have only
recently experimented with the classes, and from those who don't yet
understand them.
The most meaningful critique comes from one of the most reliable
sources. Aaron Hillegasse was an original NeXT employee and I think his
opinion is very weighty.
My personal objection is of the creation of Panther-only frameworks,
when patching Jaguar would be trivial (if the nature of the frameworks
is as advertised), and the motivations for not doing so are
disingenuous.
--
Brent Gulanowski email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.