9 Dec
2008
9 Dec
'08
1:06 p.m.
I know it all makes sense from your point of view, but
I'd ask that
you at least consider my viewpoint.
Okay, let's take this a piece at a time.
As an Architect in a Fortune 500 company, I see many
developers come
into our environment and promptly start wreaking havoc by writing
their own solutions for things already available:
* [...] Yes, some apps are horrid, but in this
environment, it's
often better to demand better quality from the vendor than try
to re-implement and support an internal app.
And what do you use in the meantime?
I went through my larval phase under VMS in the '80s. We submitted
numerous bug reports (SPRs, they called them) to DEC. The only one we
ever got anything at all back in response to was one which was my own
mistake.
No fixes. No patches. Not even an acknowledgement that the problems
were problems.
Later, I worked on a project with JPL, under SunOS (this was before
Solaris). They'd bought the right to access internal support techs at
Sun. By the time we had to call them, it almost every case (I think
every case, but it was long enough memory is going fuzzy) we knew the
relevant part of the system better than the tech we spoke with did.
I am deeply cynical about vendor support. With reason, I believe.
* They don't want to learn how to use an
established app. In my
opinion, the quality of a developer is his willingness to
understand an environment he/she did not create.
That doesn't sound much like a develoepr to me. Developers develop;
understanding others' work is more an attribute of users and
maintainers.
Doing this denies an established project the resources
of a great
developer (the GCC team could use some good assembler/compiler
developers to push that platform ahead for all of us),
I've tried. The gcc people do not appear to be interested in any of
the things I've done to gcc.
Furthermore, speaking of it this way betrays a paid-developer
mentality, which is severely inappropriate for volunteer projects like
gcc: the project does not have the resources of the developer in the
sense that an employer does, the sense of being able to call on them at
will for whatever the project wants done.
I write code becayse I enjoy writing code. If it's useful to me,
that's a substantial benefit (and there are enough things to write for
which I want the functionality that the issue of having nothing useful
to write doesn't arise). If it's useful to others, that's even more of
a benefit. But it is not nearly as much fun for me to fetch something
from somewhere else and wade in with a machete to make
it build for me
as it is to build my own. At work, I'm much readier to install
a
prerolled package than I am at home; the tradeoffs are very different.
Again, this comes back to the difference between the paid-developer
mentality which you as "an Architect in a Fortune 500 company"
presumably (and reasonably) exhibit at work, and the
volunteer-developer world that is far better represented on this list.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B