Productivity: Quantity or Quality?

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 02/28/05 

Date: Mon, 28 Feb 2005 18:59:39 GMT

Randy wrote:
> T.M. Sommers wrote:
> > Randall Hyde wrote:
> > > The problem with performance is that
> > > software engineers have *far too long* relied upon the
> > > effects of Moore's Law to cover the performance aspects
> > > of their projects. Some of us just happen to believe that those
> > > who take the attitude "There is no need to write efficient code"
> > > are being socially irresponsible.
> >
> > Or maybe the programmers who spend their time writing new, useful
> > programs rather than spend it trying to squeeze a few cycles out
> > of existing programs are the socially responsible ones.
>
> Quantity, not quality, eh?

An interesting topic for debate; Is it more "socially responsible" to
produce software quantity or software quality? Should developers focus more
on getting as much out of the door as possible or should they focus on
perfectionism of what are producing? Discuss...

The question, I think, would be: "What does the user want and need from
their software?"...

Let us return to "first principles", so to speak...why does a user want to
have any software on their machine at all in the first place?

This is not entirely "clear-cut"...because, to do a range of things, users
do, indeed, require a range of software to cater for each particular
activity they might want to do (e.g. Email, browser, newsreader,
word-processor, spread***, media player, etc.)...

But, at the same time, once the user is engaged in a particular activity
(and statistics show that Email, web, word-processing and games totally
dominate what most "average" users actually do with their machines), then
it is surely the quality of that application that then dominates?

If you like, which "goal" should developers be aiming for?

The "Microsoft model" of developing a large range of "adequate" software
for all manner of activities to "dominate" all user activity...that is, to
focus on "getting as much out the door as possible" of reasonable-ish
quality to focus on having a wide range and number of available software to
the users...here, "productivity" is being defined in terms of
"quantity"...the more you produce, the better...the "priority" is the
amount produced, not so much the quality of what is produced...

This model is typically pursued by commercial organisations, who dream of
emulating the Microsoft "monopoly" success (after which I've named this
"model" because, basically, Microsoft are the best examples of a
corporation intent on this kind of "goal")...

[ A cynical but quite accurate thing to note is that in a "boss / employee"
relationship, it is very easy indeed for a "boss" to measure their
employee's "productivity" when it's measured in _quantative_ units of
things like "applications out the door", "lines of source code written",
"amount of hours worked", etc....qualitative units are harder to measure
and, indeed, may often require "expert knowledge" to realise that though
some "feature" may be taking its time for the programmer to produce, there
is inherently a good reason for this - it's a complicated feature - and
that it is worth waiting for because it's a "killer" feature... ]

Or the "Niche model" of developing each individual application to a high
level of quality, to meet that particular "niche market" as best as
possible...

[ And this is something else to note...consider Visicalc, the original
"killer app" spread***...infamously, Lotus and Microsoft basically
"stole" the spread*** concept from a lone developer who knocked people
sideways with this very successful "killer app" that was good enough to
often be the _sole reason_ businesses purchased a computer, in order to
process their accounts...this is what made it that "killer app": It was so
useful that this one bit of software could actually sell machines all by
itself...

But the question is: Could this application have developed under a
"quantity" regime? After all, Lotus and Microsoft didn't come up with it
but simply "took" the concept when it proved successful...if targetting "as
much out the door as possible", then, as was the "norm", a simple
"calculator" application would be the natural target...the user would then
use the "calculator" to do their work and manually put it into columns and
tables with some other software like a word-processor...the spread*** is
a lot more complicated and is going to take more time to develop than a
"calculator" by its nature...but is that extra time _worth_ spending? ]

And, most importantly, if the focus is on "quantity" rather than "quality"
_CAN_ the development of such new and innovative "killer app" things
actually naturally happen?

If the developer is to focus on "as much out the door as possible" then
isn't the "strange attractor" of that going to quite naturally the
production of lots and lots of "least possible" applications? A "tendency
towards" _increasingly worse_ quality software?

Which, lo and behold, as the "Microsoft model" tends to dominate, is
_exactly_ what we've seen happen over the decades since this "model" took
hold..."bloatware" that more and more wastes computer resources and user
time, simply to promote "developer productivity"...

And _ARE_ users - the ultimate judge and arbitrer of our software (if they
don't buy / use it, then what was the point of development in the first
place?) - actually happy with what the "Microsoft model" has given them?

What are typically users' chief complaints? From my experience, "cost" is
the biggest one...that the newest piece of software always requires a
hardware "upgrade"...but, in return, the "upgrade" is not appreciably
faster, more featured or generally "better" in any kind of "proportional"
way to the _cost_ the user just forked out...you know, the user has had to
scrape together $1000 for a brand new machine to meet the "minimum
specifications" of the newest Windows (plus, of course, the $100 or so for
the new Windows itself :)...that's quite an investment for many
people...so, what are we getting for our money? Windows 95 -> Windows 98,
it was "USB support", "IE integration" (which people actually often didn't
want at all and the DoJ filed an anti-trust action against Microsoft for
including) and a few minor "adjustments" and "tweaks"...$1000 or so for
effectively getting little more than "USB support"?!? Windows 98 -> Windows
ME...well, _was_ there any appreciable difference for the cost paid out?
Obviously not too much because ME's existence is often "skipped" by users
completely as if it never existed in the "chain"...

ME -> XP? Well, there is an appreciable difference but it's a _DECEPTIVE_
one...XP is vastly improved on ME, so, to first appearances, it seems
Microsoft have worked to actually _justify_ that "investment" in all the
new hardware to run it...BUT appearances can be deceptive...internally, XP
uses 2K drivers and binaries...internally, XP thinks it's 2K...and the
difference between 2K and XP is almost non-existent: The interface graphics
have been "improved" but that's just changing bitmaps and fonts
around...and there was "backwards compatibility" added for the 9x range of
Windows (but, then, this is not really a "feature" but a "persuasion" to
upgrade...you know, it, yes, allows you to know that the "upgrade" is
probably "mostly safe" that your old applications _should_ still run...but
you don't just "upgrade" _for_ that feature itself...that would be
nonsensical, as, of course, nothing has better "Windows 98 compatibility"
than Windows 98 itself...this is not really a "feature" or _justification_
for upgrading but rather a device used to ensure that the "upgrade" goes
smoothly...so it really cannot count)...

Hence, in fact, Microsoft have just re-branded the NT range and dropped the
9x range..."merging" the two into one...in absolute terms, they've, again,
done very little indeed to "justify" the upgrade costs but, in relative
terms - because they were always selling an inferior product in 9x - it
seems like a "leap" because they've now started selling their previously
"business range" NT OSes to home users at "home user" prices...so, in fact,
XP is not really "new" but rather a "special offer" to drop the NT kernels
into the "home user" price range and featureset...

Anyway, this tends to be the user's chief complaint...the current software
model, which emphasises this constant "upgrade", keeps asking them to shell
out for better hardware all the time and what one gets in return is hard to
consider "justified" next to the cost...

Next up, users regularly complain about software defects...not surprising,
really...after being "coerced" into paying for all this new hardware to
"upgrade", the software is then full of unacceptable defects (but
developers call them "misfeatures" or something to try to psychologically
pretend that broken, defective, "reject" software is somehow "acceptable"
to sell to people)...after paying to "upgrade" to Windows 98, the user
discovers that it crashes to the "Blue Screen of Death" with alarming
frequency...and perhaps developers should be forced to use their own
non-backed up "important" work as "test data" for the message to get across
that a crash is NOT "minor"...hours of work vanishing, "customer data"
that's not possible to retrieve again (not without appearing so terribly
"amateurish" to your customers to have "lost their file") utterly lost,
etc....

Yes, important data should be "backed up", of course...but this should, in
the norm, be a total "redundency" and not constantly actually _needed_ to
"patch over" bad quality software...well, put another way: Wearing a safety
belt in a car does not "excuse" dangerous driving...wearing a hard hat
doesn't "excuse" playing the fool in a dangerous building site..."backing
up" data does NOT excuse software from operating correctly and reliably...

Related, users actually interested in "more features"...this is another
fallacy...users are interested in _USEFUL_ features that ease and aid their
work, NOT simply "numerically greater" numbers of features...indeed, "more
features" is often the shallow, hollow "justification" for the "constant
upgrade" cycle...you can't keep releasing the same software over and over,
expecting the user to pay for something they already have...so, change the
bitmaps around, add in a "new feature" that, in fact, no-one uses or wants
but this makes it "version 2", which "justifies" the "upgrade"...

Note, yes, _GOOD_ and _USEFUL_ "feature" enhancements _ARE_ wanted by
users...but it's, again, a _QUALITATIVE_, not quantative measure...software
is not "better" simply because it has longer drop down menus...indeed, the
very best software provides the "new features" _WITHOUT_ overly
complicating the interface...it's all made "integral" and "intuitive" into
the interface itself...

There _IS_ a condition of "feature overload"...I've _SEEN_ it happen with
"clueless newbie" users (I often help out people with fixing their computer
problems and, thus, when I talk about "what users want", this is _direct_
from those users, not simply "theory" of what I just "think" they might
want)...there's so many buttons and menu options and such, that they are
just "lost"...it even quite literally "gets in the way" that the visual
confusion makes it harder to remember which menu option does what...it
exceeds "brain capacity" and becomes a _problem_...programmers may not
always appreciate this because we _develop_ our "skills" to be able to
"mentally partition" things as part of being a developer...but, well,
"science" (left hemisphere thinkers) people will find it simpler than "art"
(right hemisphere thinkers) to do...the problem is that programmers and
developers quite naturally tend to be "left hemisphere" and then forget to
"account" for the "right hemisphere" people...and, of course, to do it
properly, one needs to be "lowest common denominator": Cater for the "right
hemisphere" people because they are the ones who'll have the most
difficulty, while "left hemisphere" is not in any way prejudiced by a
"cleaner and simpler interface"...they probably could handle more
themselves but, to do so, would "alienate" the "right hemisphere"
thinkers...

But, as I say, the real problem here is that developers tend to be
"scientific / mathematical" people who naturally are good at this kind of
thing...and, thus, developers using themselves as the "model" to develop
to, tend to make the slight mistake of creating very "left hemisphere"
interfaces...lots of options, arranged into "hierarchies" and that kind of
thing..."right hemisphere" people panic at things like that...you know,
their "interface style" is the "intuitive" style (no, NOT "automated"
necessarily but "organic" in its usage...indeed, "organic" is the word for
"right hemisphere" people :)...

Though, as always, the _true_ point is about "balance"...if you spit out
software like one of those tennis ball machines, then quality tends to
suffer (and it's like those comedy sketches where someone is playing tennis
with the "ball spitter" machine happily but then someone distracts them and
the ball smacks them in the face...grabbing their head in pain, another
ball smacks them elsewhere and, suddenly, oops, you're now just pelting
_sadistic punishment_ at your user, not really "helping" them at all:
"Stop! Stop! No more!" ;)...if you spend 7 years working on just one
"perfectionist" routine, then your quantity suffers (yes, apparently, DOOM
7 will be absolutely fantastic...unfortunately, it's so good, that it'll
take until the year 3057 before release...this "lets down" the user in the
other way that they are waiting there for the "ball spitter" machine to
start firing tennis balls and, ummm, nothing's coming out)..._NEITHER_ is
particularly desirable, in fact...

What we, of course, need is a "ball spitter" machine that will fire the
tennis balls at a useful rate and, better yet, is able to "adapt" to the
user...so, you know, if users are happy enough with what they've got or
want to go off and talk to someone, the "ball spitter" stops firing,
waiting for them to be "ready" again...

I'd say: Quality _THEN_ quantity...note, that's NOT "mutually
exclusive"...you attempt to "balance" a little of both...and "quality" is
_prioritised_ because, well, you know, what's the point of six million
programs that don't work and are completely broken? But, the truth is, one
shouldn't "get carried away" in either direction...because there's a
"dominance" of "quantity, screw quality" attitudes then it's tempting to
reverse it and say "quality, screw quantity" in response...but that would
actually be an "over-reaction"...what I'd say is needed is what's almost
always needed: A _balance_...unfortunately, such things are always
typically difficult for humans to achieve because we tend to get "obsessed"
or "carried away" in one direction or the other...

If you like, in "HLL vs. ASM", no-one is actually "right" or "wrong"...or,
if you like, both sides are simultaneously "right" and "wrong"...because
HLLs were developed to deal with a _REAL_ "productivity / too many bugs"
problem...problem is, this "solution" isn't itself without
"issues"...indeed, what really happens is that "efficiency" and "quality"
get "traded off" for the developer spitting out code quickly...leading to
"bloatware" and, ironically, the complexity brings _bugs_ straight back
into the equation (HLLs are _supposed_ to improve the "bugs" situation but,
really, it's quite an inescapable _inherent_ problem so all HLLs do is
_change the nature_ of the bugs but they don't "eradicate" them any which
way at all...it's a "misunderstanding" of "abstraction" to think it could
ever possess such a "power" to somehow produce "bugless" code, just because
it's "higher-level"...nope, that would just "diffuse" the bugs, in
fact...ironically making it often slightly more difficult to "debug"
properly :)...

And it's very interesting to note what emerges as the "norm" for most
"serious" developing: C / C++ coding...and that's not without reason, I'd
say...C is "the lowest of the low" of HLLs and, thus, development is drawn
towards it generally because it's neither "too low" nor "too high"...low
enough to be _useful_, high enough to be _productive_...and we see "inline
ASM" because this allows a quick "dip" into the "low-level" when it's
needed...but, at the same time, C uses "libraries" an awful lot and these
could provide any level of "abstraction", really...then C++ adds on "OOP"
for "order and organisation" in the code...

And that's why C / C++ tends to "win" because it's got the "balance" about
right...think about it, when people use little "helper" macros in ASM, they
tend to add in exactly the "if", "while", "for", "switch", etc. control
constructs that C provides...and the nigh-on universal presence of "inline
ASM" in most C compilers is "no mistake"...sometimes they need to "dip"
down to the "low-level" to do something too...

This is why the _real_ "future" is "multi-level languages"...it's really
rather logical...sometimes you need "low-level" and, so, most HLLs are
_useless_ in that capacity because they "prohibit" the "low-level"...and
sometimes you need "high-level" and ASM is capable but, boy, do you have to
write an _awful lot of code_ to get there...we _CAN'T_ say that "all
applications are low-level" so we can't say that "low-level" is "always"
the best option...and we _CAN'T_ say that "all applications are
high-level", so we can't either say that "high-level" is "always" the best
option too...

People often say "the right tool for the right job"...thus, if you're about
to do some "do it yourself" or building work, do you just take along just a
hammer? Or do you take along a _TOOLBOX_, full of all different tools? The
point to make, probably, is that a "job" is not necessarily "uniform"
throughout (so, really, "it's right _TOOLS_" - plural_ - "for the right
job" :)...for example, putting up a shelf: You need a drill, a "spirit
level" thingy, a screwdriver, screws, those "plug" things to stop the
screws slipping out, someone to "nag" at you constantly to actually get
around to doing it because you'd rather be "lazy" instead, etc., etc. ;)...

So, I'd say, in the phrase "quantity, not quality, eh?" that the reverse
"quality, not quantity, eh?" would be equally problematic...what you want
is "quality _THEN_ quantity"...the key phrase is actually "not" there, not
which way around you put "quality" and "quantity" other side...you want to
change "not" - this bizarre presumption that it's "mutually exclusive" - to
"then" because, yes, I'd say "quality" has the _priority_, for sure...but,
well, the point is that the "mistake" in "quantity, not quality" is
_abandoning_ one in preference for the other...it might be marginally
better - but not much - to simply reverse what you "abandon" as a
reaction..."abadoning" one or the other _IS_ the actual problem, not
"which" to completely throw out the window...the problem isn't "which
side?" but that we're stupidly "taking sides" in the first place..."war" is
not the "solution", war is the entire _PROBLEM_ itself...

Beth :)