Linux-Advocacy Digest #727, Volume #25 Tue, 21 Mar 00 07:13:04 EST
Contents:
Re: Producing Quality Code (Mark Hamstra)
Re: Producing Quality Code (mlw)
----------------------------------------------------------------------------
From: Mark Hamstra <[EMAIL PROTECTED]>
Subject: Re: Producing Quality Code
Date: 21 Mar 2000 06:41:20 -0500
Let me preface this reply with a brief parable that I hope will
make some of the issues clearer.
It seems there was this river gorge and a railroad company with a
bit of a problem: they stood to gain a considerable sum if they
could transport goods from one side of the gorge to the other --
but there was no bridge. All was not lost, however, because there
were a couple of groups of engineers ready, willing, and able to
build the necessary bridge. Hooray!
Sadly, the problems weren't over. It seems that the goods to be
transported were 500,000 liters of ice cream... but there are no
refridgerated railcars... and the train has already left the
factory. In otherwords, time is the overriding factor. If you
ignore the time factor, the best you can hope for is significantly
decreased profits from a lot of melted ice cream, but the worst
case will be a horrible train wreck.
Now it also seems that there is a considerable quantity of twine,
timbers, and baling wire already on the premises. There's also a
decent granite quarry site just up the river, and limestone a
little further away. From the pure bridge builder's perspective,
building a lime kiln, firing it with some of the available
timbers, quarrying and shaping granite blocks, using more of the
timber to build caissons, sinking the caissons to bedrock,
building foundation piers from the granite, and finally using the
lime mortar and the rest of the quarried granite to build a rail
bridge that will last a thousand years is the proper use of the
materials and skills at hand.
Except for the trainwreck.
On the other hand, you could use the timbers, twine, and baling
wire to throw up and lash together a barely adequate bridge just
before the train arrives.
The smart engineers and construction managers recognize the
constraints of the economic model that they are forced to deal
with, so they choose to build the technically inferior lashed
timber bridge, even though they know it is severely limited in
the loads it can carry, requires huge amounts of maintenance to
keep it from rotting away into the bottom of the gorge, and may
even get washed away by the first good sized flood.
Running around on the banks telling the engineers how foolish
they are being for not building a proper stone bridge won't get
you much beyond dirty looks and harsh words -- the train is
still coming. Explaining to them that they hold tremendous
power because, if they were all to declare that they refused to
build anything but a proper stone bridge, then the company
would be forced to oblidge them won't do you any better -- they
fully realize that if they don't build the timber bridge in
this location (which they carefully chose as the best bridge
site), then there is another bridge company that has secured
the rights to another, slightly lesser site a little ways down-
stream, and they will likely build a quick timber bridge and
end up with the railroad running through their site.
So, if you want to build stone bridges, then you've got a
limited number of choices: 1) Choose projects that don't have
unavoidable time constraints; there are a few of these jobs
available -- building little bridges in private gardens and
such -- but there are many more "do it fast" jobs, and they
pay a lot better. 2) Do everything possible to change the
shipping schedule -- slow down the train; but if there's
nothing that you or anyone else can do to change the train
schedule, then you're just wasting effort on an idealistic pipe
dream. 3) Put in the time and effort to build a stone bridge
regardless of the trains and other bridging companies. You're
going to miss out on the first trains and big money, and the
railroad is going to be in place across the timber bridge by
the time you've got your bridge done to the point where it
can handle the job, but if you clearly think through the
economics (and maybe get a little bit lucky), you might still
make the effort pay off in the long run. Perhaps there are
bigger trains or loads coming in the future -- loads or rail
gauges that the timber bridge can't handle -- then the railway
may well be diverted to your bridge in the future. Maybe the
timber bridge crew is making money not from building the bridge
itself, but by charging tolls to cross it. If you don't change
tolls for your stone bridge, then maybe you can get a sizable
amount of traffic across your bridge. Of course, you're not
getting any money directly from that traffic, but maybe that's
ok. Maybe you're content with just seeing your work used for
the good of the community and don't care that you aren't
getting much beyond the occassional thanks or token of grat-
itude. Or maybe you actually planned ahead and built a barge
facility on the river at the same time, and now have a success-
ful trans-shipping operation going at the bridgehead.
Or maybe none of that is true, and the only result of your
efforts is that there is this weird stone bridge out in the
middle of nowhere with nothing at either end of it. Of course,
nobody ever uses it... or even goes near it on account of the
crazy old hermit up there that keeps going on about the
injustices of the world and how if everyone would refuse to
book passage on the passenger trains until the railroad agreed
to move the lines to use this much safer stone bridge, then
we'd all be better off.
Ok, this has gone on more than far enough....
[EMAIL PROTECTED] writes:
> In article <[EMAIL PROTECTED]>, Mark Hamstra
><[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] (mr_organic) writes:
> >
> >> On 20 Mar 2000 15:00:12 -0500, mr_organic pronounced:
> >> >
> >> >Your premise that poor software quality is an acculturated
> >> >result of marketing driven decision making and engineers who
> >> >do not take their craft seriously is flawed (although the
> >> >thread about poor understanding of fundamentals engendered
> >> >through tools that isolate their users from understanding and
> >> >the bit about overly complex systems have some merit.)
> >> >
> >> Marketeering is what drives modern buying decisions, which
> >> in turn forms other business strategies; in this, it is a
> >> self-perpetuating medium. The media/marketers whip up
> >> demand for a (usually vaporous) product; users clamor for
> >> the product; business then rush to produce the product.
> >
> > Nope, marketing is only part of the process. Yes, it can be
> > critical to this business model in the early stages, but it
> > is no more the determining factor in closed source software
> > development than is the match that starts a forest fire --
> > critical to getting things started, but not nearly so
> > important once the whole process is fully engaged. Regardless
> > of marketing, most Windows users couldn't switch OSes now if
> > they wanted to, and neither can many people change from
> > proprietary software tools and data formats.
> >
>
> What's stopping them, apart from simple inertia? Granted, it
> would be a hassle to convert document formats and retrain
> for new applications, but corporations did it once, and will do
> it again; why not now? This is an empty point, but everyone
> seems to have bought into it. Dropping Windows is not an
> impossibility; it simply takes imagination and foresight,
> along with a willingness to be flexible.
And a great deal of time, effort, direct and opportunity costs.
In otherwords, there damn well better be a significant pay off
resulting from such a transition, because if the new stuff only
does what the old stuff did, then what was the point of changing?
In fact, simply substituting new software for old may never be
a pratical reality in some domains. For example, do you really
want to try to come up with economically sensible means to
convert the millions of existing AutoCAD DWG files that are
already in existence? The companies that created those files
still need to use them, so abandonment is not an option. If you
can't provide feasible means to make use of that data in your new
software, then those companies will be forced to maintain two
parallel systems -- and that's not at all attractive. It's not
impossible to do, but there have to be some pretty large incent-
ives to make it even worth considering.
> > These are fundamental economic issues, at have little to do
> > at the point of full engagement of the proprietary software
> > engine with marketing efforts or principled stands by
> > software engineers. If you don't fully understand the forces
> > of economy in play, then you stand to be spanked by Adam
> > Smith's invisible hand.
> >
>
> Whenever I hear economists ramble on about "market forces",
> I want to reach for a gun. We are at a stage where computer
> software is becoming essential to the functioning of our
> society, which in my mind places it in a fairly special category.
> It is not a "product" or a "good", but closed-source software
> companies insist on selling software as if it were a product.
> It is becoming increasingly apparent that software is a *service*,
> and that the code we write is simply one piece of the delivery
> mechanism.
Software is only rarely being used and distributed as a service.
In fact, much of what service there is to software under the
current model is to the software vendors' benefit: it serves to
allow them to exploit their userbase. There are very few products
or goods that give their vendors the degree of leverage over the
vendor's customers that software does. Software is currently no-
where near a service model when it can often be used by the vendor
to the customers' disservice without much market penalty or con-
straint.
Perhaps what you mean is that software *should* be a commodity
service that works to the benefit of the vendor exactly in so far
as it works to the benefit of the consumer, but that is a long
way from reality at present.
> >> Engineers are usually aware of this dichotomy, but elect to
> >> put up with it rather than protesting strongly and acting
> >> as agents for change.
> >
> > Engineers with inadequate understandings of economic realities
> > make poor agents provocateur in the software marketplace.
> > Those who understand and respect the realities stand the best
> > chance of making a difference.
> >
>
> Crap.
Go ahead and try it, but I can just about guarantee you that your
efforts at convincing will be wasted on the engineers building the
timber bridge unless you can show them how your stone bridge idea
is going to pan out to their benefit in the end.
> And crap again.
Hardly. Figuring out how to make a stone bridge pay for itself
when the railway is already running across a quickie timber bridge
requires a sharp understanding of the economic issues and
alternatives at hand.
> Business majors make crappy software
> engineers, and vice versa.
But this isn't just about engineering software, but also about
re-engineering and re-directing the fundamental economic forces in
play. Just knowing how to build a stone bridge or just knowing
how to make a stone bridge pay for itself is not enough, you must
understand both or you are doomed to ineffectuality.
> Arguments like yours are part of the
> reason we're in the mess we're in vis a vis software. If
> "economic realities" mandate shitty code, then we are all in a
> world of hurt.
My arguments didn't create the current marketplace any more than
did the decisions of any individual software engineer or user.
We are indeed in a world of hurt (unless you've already got your
hundred billion and don't care much beyond that), which means
that understanding how we got here and what are the viable means
of escape are all the more critical.
> >> >Poor software is not motivated by marketing decision making,
> >> >it is fundamental to the core business model: lock in users
> >> >to a proprietary platform as early as possible in order to
> >> >establish strong network effects. In such a model, speed is
> >> >of the essence -- it is more important to be first than to be
> >> >right -- and software quality suffers as a result. That is a
> >> >business model that works (at least in terms of generating
> >> >revenue), and is the one followed by pretty much every
> >> >successful software vendor (again, measured in monetary terms).
> >> >That strong marketing is essential to such a model is not the
> >> >same thing as marketing being the prime mover of the system.
> >> >
> >> I disagree; see my previous comments.
> >
> > I have, and they're flawed.
> >
> >> >Furthermore, it is not the case that engineers working within
> >> >such a business model have no respect for their craft -- but
> >> >they are severely restricted by the constraints and demands
> >> >of the business model. While there are definitely some
> >> >engineers and companies that seek to deliberately exploit
> >> >lock-in and network effects with little or no regard for design
> >> >and product quality fundamentals, there are also a large number
> >> >of coders who would dearly love to be able to write software
> >> >that they could be proud of for its technical elegance and not
> >> >just for its ability to generate revenue -- although most of
> >> >them are not willing to give up personal revenue in order to
> >> >acheive that pride in product.
> >> >
> >> >Only by providing a successful alternative to the dominant
> >> >software business model will you be able to acheive any
> >> >significant change in software quality. Jihads and insulting
> >> >pontification will gain you nothing in terms of software
> >> >quality -- and will likely generate nothing beyond ill will.
> >> >Instead of engaging in easy polemics, you need to contribute
> >> >to the hard work of creating software that can break the
> >> >business model and established network effects that chain us
> >> >to poor software quality. To date, Open Source software
> >> >development is the only option that shows any promise of
> >> >generating a return on that hard effort.
> >> >
> >> >--
> >> >Mark Hamstra
> >> >Bentley Systems, Inc.
> >>
> >> First, I object to your terminology -- "easy polemics" and
> >> "insulting potification" are inflammatory words, and I do
> >> not thing my orignal post indulged in either.
> >
> > Yes, I am sure you are correct that other engineers love to
> > be told they have no respect for their profession or pride in
> > their craft, that they should stop being so foolish and "Just
> > Say No". The slogan didn't work when Nancy Reagan didn't
> > understand the realities of drug addiction and economics, and
> > I wouldn't expect it to be much more successful when applied
> > to software.
> >
> >> You seem to
> >> be one of the engineers who simply throw up their hands and
> >> say, "What can I do?"
> >
> > Part of what I mean by "easy polemics" and "insulting
> > pontifications": you have not a clue who I am or what drives
> > my decision making -- and just for the record, I am currently
> > in the process of assuming a great deal more responsibility
> > and personal financial risk in an effort to make a difference
> > in the portions of the software market I care most about, so
> > your straw man could hardly be more inappropriately placed.
> >
>
> I made no judgement about you personally (although I must
> have hit a nerve if you took it that way).
And how exactly was I supposed to take "You seem to be one of the
engineers who simply throw up their [sic] hands and say, 'What can
I do?'" impersonally?
> I will say that your
> "realities of economy" fooferaw is the same kind of fatalist
> B.S. that has gotten software into this sorry state to begin
> with. As a group, computer people seem to be hobbled by
> greed -- we express noble intentions, but lose our backbone
> when presented with fat stock options or the threat of loss of
> pay.
Fatalistic rationalization or any other kind of "fooferaw" have
next to nothing to do with how we got into this situation.
Market forces are not the result of macro theorizing or decision
making with an eye to a global strategy; rather, they are the
result of millions of micro decisions made in a local context.
The corollary is that, once established, those market forces will
not be changed by any high-level strategizing that fails to
create the conditions under which millions of counteracting micro
decisions will be made in a purely local context -- even the best
revolutionaries in history could not rally the masses to a grand
strategy except for the brief moment while that strategy ran
parallel to the common and quotidian concerns.
If you don't understand that, then your revolutionary strategizing
will either look foolish in its isolation from concerns of the
proletariat, or it will be doomed to be a flash in the pan of no
lasting importance.
> >> It means doing more than simply paying lip-service to writing
> >> good code. It means not only writing good code yourself, but
> >> not putting up with less from anyone else, either. It means
> >> making sacrifices to enforce good code -- eschewing the new
> >> release of WhizBangProd 1.0 just because it has niftier graphics
> >> or a multimedia layer, for example, until the vendor fixes bugs.
> >
> > "Just Say No" isn't going to get the job done, and getting
> > insubordinate to the point of risking significantly decreased
> > revenues under the current business model is likely to get you
> > nothing but fired. Only through providing enough functionality
> > to get the job done and tangible benefits that the proprietary
> > model can't match can the Open Source effort hope to break the
> > constraints of the current software market.
> >
>
> How many software companies would survive if no programmers
> would work for them? That was my whole point; programmers are
> the most important part of the process, and yet they have no
> sense of their own power.
Programmers have little influence in isolation, only through
collective action -- and that simply ain't going to happen.
There are far too many diverse and strongly held opinions among
programmers for them ever to act as a collective. At best,
you'll convince a group of programmers at a company to put their
company at the mercy of its competition's sense of opportunity.
Once that company is mauled in the marketplace, you'll have a
very much tougher time convincing your next band of revolution-
aries.
> We still are mired in the belief that
> we can lose our jobs and be destitute at any moment (or lose
> millions in vested stock options). Your argument seems to boil
> down to nothing more than "status quo" -- leave things alone and
> maybe it'll get better.
Again, your willingness to attribute arguments and motives to
others when they disagree with you is at least galling. I
have no great love for the status quo, and neither do I advocate
a laissez faire attitude. That I don't happen to be pursuaded
by your poorly focused revolutionary sloganeering should not be
construed to mean that I am in the vest pocket of the keepers of
the status quo, and your efforts to do so are offensive.
> Well, there's no evidence of that; if fact the
> situation is worsening at an alarming rate.
Agreed; so we have little time and resources to waste on poorly
conceived efforts.
> >> For myself, posting the original memo was the first part of my
> >> own project to raise awareness to the issue; the next step is
> >> to evangelize it in my own circle of developers. If the ill-
> >> will of lazy programmers is the worst I suffer, I'll be glad
> >> of it.
> >
> > I couldn't care less about ill will that you engender among lazy
> > programmers, but you are equally or more likely to offend the
> > good ones at the same time, and that's not a particularly good way
> > to garner quality support. While ill will may be the worst you'll
> > suffer, it's also likely the most you'll gain -- in which case,
> > what's the point?
> >
> > --
> > Mark Hamstra
> > Bentley Systems, Inc.
>
> You persist in seeing things in terms of how they are -- I speak of
> how things *can be*,
No, you persist in mistaking how you want things to be as being
adequate in itself as a guide to how to effectuate change.
> given willingness of people to effect change.
And they won't give you that en masse based upon high-level
theorizing; you have to offer them an option that makes an
immediate difference in each of their individual lives today.
Railing about how we could force the city to replace the
wastewater treatment facility if we would all just flush our
toilets at exactly the same time is foolishness.
> If all this dialogue garners is ill-will, wouldn't you say that there
> is a larger problem among the ranks of programmers? After all,
> all I'm advocating is rigor and quality in a field that desperately
> needs it.
>
> What's so frightening about that?
There's nothing frightening about it in isolation. The problem
is that software quality is not orthogonal to other very real
and powerful concerns. You must address those concerns in order
to effectuate change -- ignoring them is not enough, and insulting
those who recognize them is worse.
--
Mark Hamstra
Bentley Systems, Inc.
------------------------------
From: mlw <[EMAIL PROTECTED]>
Subject: Re: Producing Quality Code
Date: Tue, 21 Mar 2000 07:08:34 -0500
n@- wrote:
>
> In article <8b6t9i$5q1$[EMAIL PROTECTED]>, "by" says...
>
> >Also, I think those are the kind of questions they ask you when you go apply
> >for a programming job at Microsoft. At least the group who interviewed me
> >asked me those kind of questions, and I had to write a bunch of code on the
> >spot, including a recursive binary tree walk.
>
> Asking some very specific questions like these do not make sense.
> After all, 99% of programmers these days use re-usable library
> components where all of these algorithms are allready written.
>
> How many of you actually write a linked list from scratch any more?
> how may write hash tables? etc.. if you do, and unless you have a
> very good reason to do that, then you are wasting the employer
> time and money, becuase instead you should be simply using a
> library of those routines.
This is wrong. Many of the generic libraries available are just that,
generic. For instance, you want to parse and analyze a log of data
collected over a few days worth of activity. How long do you want it to
take? One example I can give you, just recently, I wrote a program that
analyzed a set of log files, over 20 million records in all. I could
process it in 5-10 minutes. A guy wrote the equivalent program in perl,
it took over two hours to run. In the end, who is wasting time?
>
> That does not mean you do not know what a hash table is, or what
> a binary tree is, etc.. but the detailes of coding one, once you
> have done it once, are not interesting any more, it is more
> interesting to ask design issues, general software issue to measure
> the maturity of the employee on the technology of interest.
>
> A good programmer knows where to go find the library they need
> when it comes time to do it, or knows where to go look it up.
This is sometimes true, however, sometimes it is better to write your
own in a product so there are no royalties or legal issues when you
decide to market your product.
>
> A good programmer does not have to know all the detailes, as long
> as they have the brains to find out about it as needed.
This is totally false. Being a good developer is understanding the
concepts as you write code. How many times have you needed to sort 3
items? How many is the least number of compares required? Can you get it
under 3? How many data exchanges?
These are classic algorithms that, once learned, affect your thinking
and cause you to make better choices as you code.
--
Mohawk Software
Windows 9x, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit http://www.mohawksoft.com
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.advocacy) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Advocacy Digest
******************************
