21 Apr
2002
21 Apr
'02
7:37 a.m.
On April 21, Richard Erlacher wrote:
You can get the same software for UNIX, if you
don't mind the $250K pricetag.
You won't get the source code there, either, of course, but I doubt you'd
expend 200 man-years developing a piece of software at your expense and then
give away the source code. If you did, your shareholders would tar and
feather you.
Most of the software in use in the UNIX world is free. Of course
there ARE commercial packages, but...with very few exceptions, for
every commercial package there's at least one free one that does the
job as well or better. It's possible that I'm preaching to the choir
here, but one of the common misconceptions that really bugs me is the
notion that "unix == expensive", when in reality it's just the
opposite. (The same goes for "pc vs. real computers" in the "I use a
PC because I can't afford a Sun or an Alpha" case...)
People like the software for FPGA's and CPLD's
because it's either free or
under $100 US. There are so many high-quality 805x compilers that are
FPGA and CPLD stuff are some of the exceptions that I mentioned in
my paragraph above. For that stuff we're pretty much stuck with
Windows due to the shortsightedness of the vendors. There's nothing
we can do about that at this point, as far as I can tell. :-( I curb
that problem by using Windows (under an emulator of course) ONLY for
the stuff that I can't run under a real OS.
"freeware" or "shareware" that I
can't see any reason one would want one of
the $2000 types, unless he was convinced he could make his work easier by
spending that money. If people would keep after the producers of the
purportedly faulty software, it would get fixed. Vendors of shoddy software
rely on the fact that people buy their products under the mistaken notion that
it will do their work for them, knowing that, when the end-user finds out it's
not so, he'll be too embarassed to complain that the product doesn't work any
better than the comparable freeware product.
I agree 100%. Needless to say, we're trashing this compiler after
this project. :-) The fancy GUI is nice, but frankly I can be more
productive with xemacs and make.
There is a demo version of nearly every high-cost
($2000 isn't that high, btw,
though the Windows environment has made it so.) Get a comparable product for
UNIX, and you'll get no improvement, nor will you get source. All you'll get
is a bigger bill.
Not necessarily...I've used at least four FREE 8051 C compilers under
UNIX, nearly ten years ago! $2000 *is* high, when most of the 8051
compilers I've used cost $0.
-Dave
--
Dave McGuire "Mmmm. Big."
St. Petersburg, FL -Den
21 Apr
21 Apr
8:17 a.m.
Clearly we see things from different perspectives.
see below ...
Dick
----- Original Message -----
From: "Dave McGuire" <mcguire(a)neurotica.com
To: <classiccmp(a)classiccmp.org
Sent: Sunday, April 21, 2002 10:37 AM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)
That's not been my experience. In fact, until LINUX, which I don't
presently
use either, I had never seen any software of any use at all other than for
software development for UNIX. The EDA stuff I saw was not terribly useful,
but some folks managed to beat it into submission. I can't forget the
tradeshow when I ruled out UNIX in my mind. A vendor had essentially the same
software for DOS and UNIX. The UNIX version cost 50x what the DOS version
cost, and the hardware also cost over 10x the cost of an adequate PC. The two
software packages "looked and felt" as well as worked, indistinguishably once
one was inside the application.
Time was, when UNIX was the OS of choice for EDA tools because that's the
environment under which they were developed, and since they had to be patched
frequently. Whenever a patch was applied, it was likely to "reach out and
touch someone" (undesired side-effect) which meant a complete system rebuild
with lots of downtime and plenty of aggravation, not to mention a complete
lack of assurance it would fix anything.
<snip Because of the pressure from freeware, many of the 805x compilers are intended
to support a set of hardware provided by the vendor. That tends to limit
their scope.
and, for the most part, the freeware is often better than the commercial
products. I've seen little "source-available" freeware that was very good,
however. The LINUX stuff is a good example. Much of the code sits, full of
ugly hacks and undocumented modifications, among comments relevant only to the
original code that was abandoned six or seven revisions back, though it's not
obvious. It's a wonder any of it works, but it seems it does. It's unlikely
there'll ever be UNIX/GNU freeware that's as useable as the comparable
DOS/Windows stuff, though, since what looks to be the case is that nobody
wants to document the UNIX/GNU freeware.
I've got about half-a-dozen of the free
assembler/simulator/debugger packages
for Windows some of which come along with compilers for PL/M, Pascal, and 'C.'
I'm certainly not surprised that there are UNIX tools of that sort around,
since the 805x core has been around since '84 or so, when I started with it.
Back then, BTW, there was no Windows, nor was there much freeware. I used
UNIX on SUN hardware back then and it cost $100K a year for the personnel
needed to keep the rather small SUN system running. The typical EDA software
package cost over $200K and was patched about once a month, resulting in about
ten days' downtime per patch.
I was fortunate enough that my client back then was willing to take the SUN
junk and its equally loathsome OS off my hands so I didn't lose too much. I
happily went back to CP/M, which served much better, in my view.
Unfortunately, there was little freeware of any use for CP/M just as there is
for Windows. The OS was not available in source form, nor was it likely you'd
find source code for any application that was of any use. Back then, if you
wanted development software tools that worked pretty well, you bought
Microsoft compilers, assemblers, linkers, etc. Their stuff worked, was
adequately documented, etc.
Nothing lasts forever, though.
Dick
On April 21, Richard Erlacher wrote:
> You can get the same software for UNIX, if you don't mind the $250K
pricetag.
> You won't get the source code there, either,
of course, but I doubt you'd
> expend 200 man-years developing a piece of software at your expense and
then
give away the
source code. If you did, your shareholders would tar and
feather you.
Most of the software in use in the UNIX world is free. Of course
there ARE commercial packages, but...with very few exceptions, for
every commercial package there's at least one free one that does the
job as well or better. It's possible that I'm preaching to the choir
here, but one of the common misconceptions that really bugs me is the
notion that "unix == expensive", when in reality it's just the
opposite. (The same goes for "pc vs. real computers" in the "I use a
PC because I can't afford a Sun or an Alpha" case...)
People like the software for FPGA's and
CPLD's because it's either free or
under $100 US. There are so many high-quality 805x compilers that are
FPGA and CPLD stuff are some of the exceptions that I mentioned in
the stuff that I can't run under a real OS.
The FPGA/CPLD vendors would like to support everybody who's likely to use
their products. However, support is a problem under UNIX, since there are
numerous versions (I've had several) that lack compatibility. The size of the
market doesn't justify working up a freeware version for every UNIX version
though, so I think they're wise avoiding the expense. LINUX is getting some
support, though.
> "freeware" or "shareware" that I can't see any reason one
would want one
of
<snip better than
the comparable freeware product.
I agree 100%. Needless to say, we're trashing this compiler after
this project. :-) The fancy GUI is nice, but frankly I can be more
productive with xemacs and make.
> There is a demo version of nearly every high-cost ($2000 isn't that high,
btw,
> though the Windows environment has made it so.)
Get a comparable product
for
> UNIX, and you'll get no improvement, nor will
you get source. All you'll
get
is a bigger
bill.
Not necessarily...I've used at least four FREE 8051 C compilers under
UNIX, nearly ten years ago! $2000 *is* high, when most of the 8051
compilers I've used cost $0.
1:06 p.m.
It was thus said that the Great Richard Erlacher once stated:
That's not been my experience. In fact, until LINUX, which I don't presently
use either, I had never seen any software of any use at all other than for
software development for UNIX. The EDA stuff I saw was not terribly useful,
but some folks managed to beat it into submission. I can't forget the
tradeshow when I ruled out UNIX in my mind. A vendor had essentially the same
software for DOS and UNIX. The UNIX version cost 50x what the DOS version
cost, and the hardware also cost over 10x the cost of an adequate PC. The two
software packages "looked and felt" as well as worked, indistinguishably once
one was inside the application.
I did some work for a company who's only product was originally written
under MS-DOS, and I was hired to help with a UNIX port of the product. They
were planning on selling the UNIX version for about 10 times the MS-DOS
version even when (after the port) the source code is the same (except for a
few portions that hit hardware and was fairly isolated). They even refused
to sell a Linux version (even though that's the system they used for the
initial port) because they were afraid of not being able to sell it at 10
times the cost.
The reason for the disparity? Because UNIX customers are accustomed (or
were, maybe still are to a degree) to paying such prices and would view a
product that was too cheap as not being good enough. And they wanted to
offset the higher support costs that might come with the UNIX version. They
refused a Linux version for as long as they could, because they knew they
could not sell their product at their inflated price for Linux (as most of
their customer for the Linux version would be customers from their MS-DOS
version moving over to Linux).
Another company I did work for (helping with the UNIX port of their
primarily Windows product) sold the same product, from Windows at about
$1,000 a copy, to a Stratus mainframe for $50,000 a copy. Same product.
Same code base (for the most part). Why? Because they could. And the
$50,000 version fit on a single floppy.
and, for the most part, the freeware is often better
than the commercial
products. I've seen little "source-available" freeware that was very
good,
however. The LINUX stuff is a good example. Much of the code sits, full of
ugly hacks and undocumented modifications, among comments relevant only to the
original code that was abandoned six or seven revisions back, though it's not
obvious. It's a wonder any of it works, but it seems it does. It's unlikely
there'll ever be UNIX/GNU freeware that's as useable as the comparable
DOS/Windows stuff, though, since what looks to be the case is that nobody
wants to document the UNIX/GNU freeware.
So you are assuming that commercial code is somehow better than UNIX/GNU
code? Having worked at a few commercial software companies (except for IBM,
always hired to port code from MS-DOS/Windows to Unix) I can tell you that
the commercial code is full of ugly hacks and undocumented modifications,
among comments (when they actually exist---the first company I mentioned
above had, as part of their coding standards, mandated that no comments be
added to the code) relevant only to the original code. At the second
company I mentioned, the core of the product was written and maintained by
*one guy* and only *one guy* because no one else in the company could
understand the code. I saw the code in question and yes, I could see why no
one else wanted to touch this code. So code quality is just as bad (or
worse) in commercial products.
-spc (Was horrified at how bad commercial code is ... )
2:19 p.m.
On Sun, 21 Apr 2002, Sean 'Captain Napalm' Conner wrote:
So you are assuming that commercial code is somehow
better than UNIX/GNU
code? Having worked at a few commercial software companies (except for IBM,
always hired to port code from MS-DOS/Windows to Unix) I can tell you that
the commercial code is full of ugly hacks and undocumented modifications,
among comments (when they actually exist---the first company I mentioned
above had, as part of their coding standards, mandated that no comments be
added to the code) relevant only to the original code. At the second
company I mentioned, the core of the product was written and maintained by
*one guy* and only *one guy* because no one else in the company could
understand the code. I saw the code in question and yes, I could see why no
one else wanted to touch this code. So code quality is just as bad (or
worse) in commercial products.
A fairly trivial case in point - IBM's 24-bit MCA graphics adapter -
the "Sabine" card set. Several RS/6000 developers that I know claim
that the guy (singular) who developed it designed a prototype, wrote a
driver, and redesigned the hardware to compensate for limitations in his
code. Mark swears there were several cycles of that. The result was a
piece of hardware and its driver that couldn't be ported even to the
next version of AIX.
Doc
25 Apr
25 Apr
1:44 p.m.
A fairly trivial case in point - IBM's 24-bit
MCA graphics adapter -
the "Sabine" card set. Several RS/6000 developers that I know claim
that the guy (singular) who developed it designed a prototype, wrote a
driver, and redesigned the hardware to compensate for limitations in his
code. Mark swears there were several cycles of that. The result was a
piece of hardware and its driver that couldn't be ported even to the
next version of AIX.
Doc
Is that why AIX 4 dropped support for the graphics adapter?
Bill
--
d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now!
bpechter@shell.monmouth.com|pechter@ureach.com
9:01 p.m.
On Thu, 25 Apr 2002, Bill Pechter wrote:
Yes. The designer left IBM around then, and nobody in the company was
willing to take it on. Damn shame. It's an impressive _looking_
boardset....
Mark, my boss, says the v3.2.5 Sabine drivers were "the most horrible
pile of kludge" he's ever seen.
Doc
A fairly
trivial case in point - IBM's 24-bit MCA graphics adapter -
the "Sabine" card set. Several RS/6000 developers that I know claim
that the guy (singular) who developed it designed a prototype, wrote a
driver, and redesigned the hardware to compensate for limitations in his
code. Mark swears there were several cycles of that. The result was a
piece of hardware and its driver that couldn't be ported even to the
next version of AIX.
Doc
Is that why AIX 4 dropped support for the graphics adapter?
21 Apr
21 Apr
3:24 p.m.
I wouldn't say it's better, but (1) it's better documented, and (2) I
don't
have to look at the code.
Dick
----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
To: <classiccmp(a)classiccmp.org>
Sent: Sunday, April 21, 2002 4:06 PM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)
good,
It was thus said that the Great Richard Erlacher once
stated:
>
> That's not been my experience. In fact, until LINUX, which I don't
presently
> use either, I had never seen any software of any
use at all other than for
> software development for UNIX. The EDA stuff I saw was not terribly
useful,
> but some folks managed to beat it into
submission. I can't forget the
> tradeshow when I ruled out UNIX in my mind. A vendor had essentially the
same
> software for DOS and UNIX. The UNIX version cost
50x what the DOS version
> cost, and the hardware also cost over 10x the cost of an adequate PC. The
two
> software packages "looked and felt" as
well as worked, indistinguishably
once
one was inside
the application.
I did some work for a company who's only product was originally written
under MS-DOS, and I was hired to help with a UNIX port of the product. They
were planning on selling the UNIX version for about 10 times the MS-DOS
version even when (after the port) the source code is the same (except for a
few portions that hit hardware and was fairly isolated). They even refused
to sell a Linux version (even though that's the system they used for the
initial port) because they were afraid of not being able to sell it at 10
times the cost.
The reason for the disparity? Because UNIX customers are accustomed (or
were, maybe still are to a degree) to paying such prices and would view a
product that was too cheap as not being good enough. And they wanted to
offset the higher support costs that might come with the UNIX version. They
refused a Linux version for as long as they could, because they knew they
could not sell their product at their inflated price for Linux (as most of
their customer for the Linux version would be customers from their MS-DOS
version moving over to Linux).
Another company I did work for (helping with the UNIX port of their
primarily Windows product) sold the same product, from Windows at about
$1,000 a copy, to a Stratus mainframe for $50,000 a copy. Same product.
Same code base (for the most part). Why? Because they could. And the
$50,000 version fit on a single floppy.
> and, for the most part, the freeware is often better than the commercial
> products. I've seen little "source-available" freeware that was very
> however. The LINUX stuff is a good example.
Much of the code sits, full
of
> ugly hacks and undocumented modifications, among
comments relevant only to
the
> original code that was abandoned six or seven
revisions back, though it's
not
> obvious. It's a wonder any of it works, but
it seems it does. It's
unlikely
there'll
ever be UNIX/GNU freeware that's as useable as the comparable
DOS/Windows stuff, though, since what looks to be the case is that nobody
wants to document the UNIX/GNU freeware.
So you are assuming that commercial code is somehow better than UNIX/GNU
code? Having worked at a few commercial software companies (except for IBM,
always hired to port code from MS-DOS/Windows to Unix) I can tell you that
the commercial code is full of ugly hacks and undocumented modifications,
among comments (when they actually exist---the first company I mentioned
above had, as part of their coding standards, mandated that no comments be
added to the code) relevant only to the original code. At the second
company I mentioned, the core of the product was written and maintained by
*one guy* and only *one guy* because no one else in the company could
understand the code. I saw the code in question and yes, I could see why no
one else wanted to touch this code. So code quality is just as bad (or
worse) in commercial products.
-spc (Was horrified at how bad commercial code is ... )
5:47 p.m.
It was thus said that the Great Richard Erlacher once stated:
I wouldn't say it's better, but (1) it's better documented, and (2) I
don't
have to look at the code.
Better documented [1] as for using the program, yes, I'll grant you that
(to a degree). And for two, you were the one who brought up the source code
of Linux as being ``full of ugly hacks and undocumented modifications, among
comments relevant only to the original code that was abandoned six or seven
revisions back, though it's not obvious.'' So if you don't have to look
at
the code, why should this be of concern to you?
-spc (Who has looked to the source of Linux to figure out the stack frame
given to a signal handler to help debug a problem in user code ... )
[1] For various values of documented. Using only the documentation that
comes with Microsoft Word (hardcopy or the help files) can someone
be reasonably expected to learn how to use Word?
Seems like books on *using* software is crowding out books about
*writing* software at the bookstores. And to me, that says that
the documentation that comes with software is so lacking that a
market of third party documentation is viable. So I might contend
that your assertion of ``better documented'' is invalid.
8:25 p.m.
See my comments below ...
Dick
----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
To: <classiccmp(a)classiccmp.org>
Sent: Sunday, April 21, 2002 8:47 PM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)
I do have to look at the code because the documentation is irrelevant to it.
The code is on rev 13.64 and the doc is on 1.01 which is beta, and incomplete
at that. What I said was that since the commercial code didn't come with
listings, I don't have to concern myself with them.
It was thus said that the Great Richard Erlacher once
stated:
>
> I wouldn't say it's better, but (1) it's better documented, and (2) I
don't
have to look
at the code.
Better documented [1] as for using the program, yes, I'll grant you that
(to a degree). And for two, you were the one who brought up the source code
of Linux as being ``full of ugly hacks and undocumented modifications, among
comments relevant only to the original code that was abandoned six or seven
revisions back, though it's not obvious.'' So if you don't have to look
at
the code, why should this be of concern to you?
-spc (Who has looked to the source of Linux to figure out the stack frame
given to a signal handler to help debug a problem in user code ... )
[1] For various values of documented. Using only the documentation that
comes with Microsoft Word (hardcopy or the help files) can someone
be reasonably expected to learn how to use Word?
I'd say so. My 80+ year-old mother did.
Seems like books on *using* software is crowding out books about
*writing* software at the bookstores. And to me, that says that
the documentation that comes with software is so lacking that a
market of third party documentation is viable. So I might contend
that your assertion of ``better documented'' is invalid.
If programmers knew what computers were intended to do, perhaps they could
figure out what to do with them. I'd say a goodly share of what passes as
software today, including that from Microsoft, does nothing at all related to
what the user thinks it should do, based on the writeups. Further, I'd guess
that at least half of the programmers who have worked on a given piece of
software, whether for UNIX or Windows, can't agree on what it is supposed to
do. Additionally, I'd guess that, of the half that agree on what the program
is intended to do, half can't tell you whether it does that, and of that half,
another half can't tell you what their own code was intended to do or whether
it does that.
For weeks, I've been looking for a line-by-line assembler to run on an 805x
CPU. I've asked in a number of lists, newsgroups, etc, and gotten numerous
replies, all of which has convinced me that of the hundreds of millions of
people out there who fancy themselves as programmers, fewer than 1ppm even
know what a debug monitor is. I learned what a debug monitor is the day I
started using microcontrollers, back in the mid-'70's. I find this
unfathomable. Oddly enough, there are many debuggers for the 805x and other
cores, that don't even have line-by-line assembler/disassemblers in them.
Time was, every debugger you saw had one.
Back a few years, an assembler wasn't considered complete unless it could
assemble itself, and, likewise, a compiler wasn't complete until it could
compile itself. Today's tools won't do that in most cases. I think the
problem is that people don't know how to specify and how to finish a piece of
work. It's certainly true of most programmers that they simply don't adhere
to specifications based solely on design requirements. Many CAN do that, but
most won't. I'm not sure what, exactly, this means, but I suspect some
profound truth relating to the general decay of the computer software we see
these days owes its origins to it.
9:42 p.m.
It was thus said that the Great Richard Erlacher once stated:
Setting: my office at a webhosting company I used to work for.
Boss/partner comes in.
``Sean, can we do blah?'' he asks.
I think about it for a few moments. Doing blah would require this, that
and the other thing and it would take a while to get done, but ... ``Yes, I
think that's possible.''
``Good,'' he says. ``I just sold blah to a customer so we need it by
tomorrow.''
Repeat that story any number of times at any number of software companies.
Or how about:
``Oh, the customer wants the program to do yada yada instead of blah
blah.''
``But I thought we agreed that we implement blah blah and only blah
blah?''
``But the customer now wants yada yada.''
``Okay, but you just threw out foo months of work.''
``Oh, and we're still bound by the original deadline.''
And you wonder why software is so crappy?
We programmers can't agree on what to do because management, sales, or
even the customer can't agree on what they want. Microsoft is successful
partly because they have the resources to change on a dime, partly because
they control 90% of the consumer desktop market and can dictate what we
want, and partly because they have a marketing department from Hell.
Tell you what, I'll spec a program for you to write that will take, say,
six months. Two months from now I'll add some unreasonable features and the
following month, change the specs completely on you, and still hold you
responsible for the original deadline. Oh, and in month five, I'll add even
more contradictory features, and two weeks before the deadline, add the
condition that you have to support the original spec as well.
Does that sound okay?
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
Well, kudos to her then.
[1] For various values of documented. Using only
the documentation that
comes with Microsoft Word (hardcopy or the help files) can someone
be reasonably expected to learn how to use Word?
I'd say so. My 80+ year-old mother did. Seems like
books on *using* software is crowding out books about
*writing* software at the bookstores. And to me, that says that
the documentation that comes with software is so lacking that a
market of third party documentation is viable. So I might contend
that your assertion of ``better documented'' is invalid.
If programmers knew what computers were intended to do, perhaps they could
figure out what to do with them. I'd say a goodly share of what passes as
software today, including that from Microsoft, does nothing at all related to
what the user thinks it should do, based on the writeups. Further, I'd guess
that at least half of the programmers who have worked on a given piece of
software, whether for UNIX or Windows, can't agree on what it is supposed to
do. Additionally, I'd guess that, of the half that agree on what the program
is intended to do, half can't tell you whether it does that, and of that half,
another half can't tell you what their own code was intended to do or whether
it does that. For weeks, I've been looking for a line-by-line
assembler to run on an 805x
CPU. I've asked in a number of lists, newsgroups, etc, and gotten numerous
replies, all of which has convinced me that of the hundreds of millions of
people out there who fancy themselves as programmers, fewer than 1ppm even
know what a debug monitor is.
Um ... you asked for a line-by-line assembler, but you really wanted a
debug monitor ... um ... so why didn't you ask for a debug monitor in the
first place?
Back a few years, an assembler wasn't considered
complete unless it could
assemble itself, and, likewise, a compiler wasn't complete until it could
compile itself. Today's tools won't do that in most cases. I think the
problem is that people don't know how to specify and how to finish a piece of
work. It's certainly true of most programmers that they simply don't adhere
to specifications based solely on design requirements. Many CAN do that, but
most won't. I'm not sure what, exactly, this means, but I suspect some
profound truth relating to the general decay of the computer software we see
these days owes its origins to it.
I think programmers can adhere to specifications based solely on design
requirements *when they don't change!* I have a friend that will *only*
program to the specifications and he demands that they don't change *at all*
or he won't do the work. And yes, he's gotten into some heated discussions
with clients about that. But he can say that he has followed the spec to
the letter, on time and within budget.
-spc (Oh, forgot to tell you ... I won't tell you the specs at all, but
that shouldn't affect the time schedule any ... )
11:15 p.m.
see below, plz.
Dick
----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, April 22, 2002 12:42 AM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)
No, I don't wonder. This situation can't be blamed on the mangers either,
though, because the programmers shouldn't tolerate this. I've jumped more
than one manager when, as chief engineer, or engineering lead, I overheard the
mgr, seemingly perched like a vulture on the programmer's shoulder said, "can
you do this?" to which the programmer says, "yes ... but..." and before
he
finishes the mgr hits him with, "well, how long will it take?" and so on
until the programmer has consented to perform 256 hours' work in the next
week, without letting any of his previous assignments slip.
This was always of concern to me when I was responsible for schedule and
budget, not to mention morale. One ExVP ultimately fired me, in part because
I jumped him every time he did that because he was so accustomed to it. He
simply beat on the guy he wanted to do the work until he told him what he
wanted to hear. If programmers would say, "OK, I can do that if you don't
mind a slip of ... on this item and a slip of ... on that one, plus 80 hours
of overtime, which I'll want as comp so I can regain my sanity before getting
back into the harness. Another thing managers hate is a memo asking them to
spell out the task assignments they've made without consulting with senior
engineering.
No ... I already have a debug monitor, in fact a half-dozen of them, but I
want to build one with a line-by-line assembler, like what was in all the ones
on which I cut my teeth. The CP/M DDT or MSDOS DEBUG is an example. Every
one of the early Motorola MCU's was supported with at least one, but often
several useable debug monitors, each of which had a line-by-line
assembler/disassembler, so you could patch code in mnemonics rather than
having to hand-assemble your code (you learned to do that quickly enough
anyway). What I wanted was some source code examples in native code for the
805x core, so I could examine them to see whether any of them could benefit
Perhaps the programmers should simply refuse to work that way, rather than
abjectly refusing to adhere to formal specifications, established policies,
etc. Either way, they're likely to be fired when all is said and done.
There's plenty of blame to go around, but if people would concentrate on doing
their jobs properly, things would improve. Too many guys focus on being a
standout rather than doing the work they were hired to do. If your manager is
really fiddling with your work assignment to such extent that you can't work
in a rigorous way, and if he's not willing to write down the reuirements he
expects you to meet, then it's time to write him a memo with a copy to his
boss.
It was thus said that the Great Richard Erlacher once
stated:
This first conclusion is flawed, methinks. The second may be valid, but I
don't thing the third follows.
It's true that there are lots of books on how to use various software
applications. Having lots of them is good because people will want to use the
software in different ways and not always in the same way. Programmers should
read these books so they know how programs are used. They should also read
them to find out how useful a helpful error or diagnostic message can help.
As for the quality of documentation, I've found statements in Linux documents
that were so outdated as to be patently false, having omitted critical terms
such as "NOT."
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
Well, kudos to her then.
> > Seems like books on *using* software is crowding out books about
> > *writing* software at the bookstores. And to me, that says that
> > the documentation that comes with software is so lacking that a
> > market of third party documentation is viable. So I might contend
> > that your assertion of ``better documented'' is invalid. [1] For various values of documented. Using only
the documentation that
comes with Microsoft Word (hardcopy or the help files) can someone
be reasonably expected to learn how to use Word?
I'd say so. My 80+ year-old mother did. > If programmers knew what computers were intended
to do, perhaps they could
> figure out what to do with them. I'd say a goodly share of what passes as
> software today, including that from Microsoft, does nothing at all related
to
> what the user thinks it should do, based on the
writeups. Further, I'd
guess
> that at least half of the programmers who have
worked on a given piece of
> software, whether for UNIX or Windows, can't agree on what it is supposed
to
> do. Additionally, I'd guess that, of the
half that agree on what the
program
> is intended to do, half can't tell you
whether it does that, and of that
half,
> another half can't tell you what their own
code was intended to do or
whether
it does that.
Setting: my office at a webhosting company I used to work for.
Boss/partner comes in.
``Sean, can we do blah?'' he asks.
I think about it for a few moments. Doing blah would require this, that
and the other thing and it would take a while to get done, but ... ``Yes, I
think that's possible.''
``Good,'' he says. ``I just sold blah to a customer so we need it by
tomorrow.''
Repeat that story any number of times at any number of software companies.
Or how about:
``Oh, the customer wants the program to do yada yada instead of blah
blah.''
``But I thought we agreed that we implement blah blah and only blah
blah?''
``But the customer now wants yada yada.''
``Okay, but you just threw out foo months of work.''
``Oh, and we're still bound by the original deadline.''
And you wonder why software is so crappy?
We programmers can't agree on what to do because management, sales, or
even the customer can't agree on what they want. Microsoft is successful
partly because they have the resources to change on a dime, partly because
they control 90% of the consumer desktop market and can dictate what we
want, and partly because they have a marketing department from Hell.
There'll always be disgreement on what's wanted, until it's written
down and
signed. If you can, get your boss to write you a "statement of work" which
includes your precise requirements including test criteria and schedule.
Usually schedule and workload can be adjusted early in the project, so if it
doesn't suit you, or, if, early in the progress of the work, you discover a
serious obstacle, that can be dealt with rationally. If you just quietly go
away, letting him plan his schedule on your acceptance of his schedule and
task loading, it's on you. If he doesn't allow you any input, it's on him,
and you should emphasize those issues in a memo. It won't help either of you
to pretend the problem doesn't exist.
Tell you what, I'll spec a program for you to write that will take, say,
six months. Two months from now I'll add some unreasonable features and the
following month, change the specs completely on you, and still hold you
responsible for the original deadline. Oh, and in month five, I'll add even
more contradictory features, and two weeks before the deadline, add the
condition that you have to support the original spec as well.
Does that sound okay?
> For weeks, I've been looking for a line-by-line assembler to run on an
805x
> CPU. I've asked in a number of lists,
newsgroups, etc, and gotten
numerous
replies, all
of which has convinced me that of the hundreds of millions of
people out there who fancy themselves as programmers, fewer than 1ppm even
know what a debug monitor is.
Um ... you asked for a line-by-line assembler, but you really wanted a
debug monitor ... um ... so why didn't you ask for a debug monitor in the
first place?
from the features and facilities of the disassembler
already on hand. Since
I'm planning to make some considerable enhancements to
take advantage of the
features of a newer version of the device, I'm wanting to get the available
stuff together and study it out before I put it together.
> Back a few years, an assembler wasn't considered complete unless it could
> assemble itself, and, likewise, a compiler wasn't complete until it could
> compile itself. Today's tools won't do that in most cases. I think the
> problem is that people don't know how to specify and how to finish a piece
of
> work. It's certainly true of most
programmers that they simply don't
adhere
> to specifications based solely on design
requirements. Many CAN do that,
but
> most won't. I'm not sure what, exactly,
this means, but I suspect some
> profound truth relating to the general decay of the computer software we
see
these days
owes its origins to it.
I think programmers can adhere to specifications based solely on design
requirements *when they don't change!* I have a friend that will *only*
program to the specifications and he demands that they don't change *at all*
or he won't do the work. And yes, he's gotten into some heated discussions
with clients about that. But he can say that he has followed the spec to
the letter, on time and within budget.
-spc (Oh, forgot to tell you ... I won't tell you the specs at all, but
that shouldn't affect the time schedule any ... )
22 Apr
22 Apr
5:10 p.m.
It was thus said that the Great Richard Erlacher once stated:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Bingo!
-spc (The Emperor may have no clothes, but he can still behead you ... )
It's true that there are lots of books on how to use various software
applications. Having lots of them is good because people will want to use the
software in different ways and not always in the same way. Programmers should
read these books so they know how programs are used. They should also read
them to find out how useful a helpful error or diagnostic message can help.
As for the quality of documentation, I've found statements in Linux documents
that were so outdated as to be patently false, having omitted critical terms
such as "NOT."
Linux, unfortunately, is a fast moving target and by the time books do
come out for the the kernel side of things, Linux has already moved on. I
suppose it's one of the prices ones pays for ever evolving code.
[ Dilbertesque situations deleted ]
No, I don't wonder. This situation can't be
blamed on the mangers either,
though, because the programmers shouldn't tolerate this.
I haven't met *any* other programmers that would even think of not
tolerating this. One friend of mine, where he worked, was asked what
hardware should be used for a new private phone switch (used to manage the
phone system at a mid sized company). They didn't listen to him and picked
PC hardware. They then asked him what OS to use. They didn't listen to him
(he wanted either FreeBSD or Linux) and they picked Windows NT.
For a phone switch.
He stayed. He bitched, a lot, but he stayed. And got it working (to a
degree). Me, personally, I would have refused to work with such crap under
those conditions but most of my programmer friends (okay, all of them)
would. And did. It came across as a challenge to them.
I consider them insane, but hey, they're still working and I'm not. So
there you have it (I've quit a job because I didn't agree with the coding
standards but that was several years ago. My current unemployment is due to
working for a completely insane boss who's goal in life seems to be to die
at work (``I had pnemonia for six weeks and did *I* take time off from
work?'' And he was back to work two days after having some heart work done)
and I took a few weeks off when I had bronchitus).
There'll always be disgreement on what's
wanted, until it's written down and
signed. If you can, get your boss to write you a "statement of work" which
includes your precise requirements including test criteria and schedule.
Usually schedule and workload can be adjusted early in the project, so if it
doesn't suit you, or, if, early in the progress of the work, you discover a
serious obstacle, that can be dealt with rationally. If you just quietly go
away, letting him plan his schedule on your acceptance of his schedule and
task loading, it's on you. If he doesn't allow you any input, it's on him,
and you should emphasize those issues in a memo. It won't help either of you
to pretend the problem doesn't exist.
Again, getting back to my friend who worked on a phone switch based on
NT---his team hired a programmer who swore up and down that he could program
under C++ and understood networking, yet three weeks later he still couldn't
compile a simple C++ hello world style program, and had no clue what sockets
are and you can bet my friend screamed up and down.
It did no good. They couldn't get rid of the programmer, and no amount of
memo writing or walking up the management chain would fix that.
-spc (Oh,
forgot to tell you ... I won't tell you the specs at all, but
that shouldn't affect the time schedule any ... )
Perhaps the programmers should simply refuse to work that way, rather than
abjectly refusing to adhere to formal specifications, established policies,
etc. Either way, they're likely to be fired when all is said and done.
23 Apr
23 Apr
6:11 a.m.
see below, plz.
Dick
----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, April 22, 2002 8:10 PM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)
What you mean here is that before the job is finished, the LINUX team has
moved on, leaving their work product essentially useless for the majority of
potential users.
Most programmers don't know their butt from a hot rock. Some of them are
smart enough to learn. Others aren't. This notion is not just limited to
programmers, however. It applies to managers, car mechanics, and physicians
as well.
It was thus said that the Great Richard Erlacher once
stated:
>
> It's true that there are lots of books on how to use various software
> applications. Having lots of them is good because people will want to use
the
> software in different ways and not always in the
same way. Programmers
should
> read these books so they know how programs are
used. They should also
read
> them to find out how useful a helpful error or
diagnostic message can
help.
> As for the quality of documentation, I've
found statements in Linux
documents
> that were so outdated as to be patently false,
having omitted critical
terms
such as
"NOT."
Linux, unfortunately, is a fast moving target and by the time books do
come out for the the kernel side of things, Linux has already moved on. I
suppose it's one of the prices ones pays for ever evolving code.
[ Dilbertesque situations deleted ]
He obviously saw things differently than you. Where one works has to be a
considered choice.
No, I don't wonder. This situation can't
be blamed on the mangers either,
though, because the programmers shouldn't tolerate this.
I haven't met *any* other programmers that would even think of not
tolerating this. One friend of mine, where he worked, was asked what
hardware should be used for a new private phone switch (used to manage the
phone system at a mid sized company). They didn't listen to him and picked
PC hardware. They then asked him what OS to use. They didn't listen to him
(he wanted either FreeBSD or Linux) and they picked Windows NT.
For a phone switch.
He stayed. He bitched, a lot, but he stayed. And got it working (to a
degree). Me, personally, I would have refused to work with such crap under
those conditions but most of my programmer friends (okay, all of them)
would. And did. It came across as a challenge to them.
I consider them insane, but hey, they're still working and I'm not. So
there you have it (I've quit a job because I didn't agree with the coding
standards but that was several years ago. My current unemployment is due to
working for a completely insane boss who's goal in life seems to be to die
at work (``I had pnemonia for six weeks and did *I* take time off from
work?'' And he was back to work two days after having some heart work done)
and I took a few weeks off when I had bronchitus).
There's a lesson there, isn't there?
> There'll always be disgreement on what's wanted, until it's written down
and
> signed. If you can, get your boss to write you a
"statement of work"
which
> includes your precise requirements including test
criteria and schedule.
> Usually schedule and workload can be adjusted early in the project, so if
it
> doesn't suit you, or, if, early in the
progress of the work, you discover
a
> serious obstacle, that can be dealt with
rationally. If you just quietly
go
> away, letting him plan his schedule on your
acceptance of his schedule and
> task loading, it's on you. If he doesn't allow you any input, it's on
him,
> and you should emphasize those issues in a memo.
It won't help either of
you
to pretend the
problem doesn't exist.
Again, getting back to my friend who worked on a phone switch based on
NT---his team hired a programmer who swore up and down that he could program
under C++ and understood networking, yet three weeks later he still couldn't
compile a simple C++ hello world style program, and had no clue what sockets
are and you can bet my friend screamed up and down.
It did no good. They couldn't get rid of the programmer, and no amount of
memo writing or walking up the management chain would fix that.
> > -spc (Oh, forgot to tell you ... I won't tell you the specs at all,
but
> > that shouldn't affect the time schedule
any ... )
> >
> Perhaps the programmers should simply refuse to work that way, rather than
> abjectly refusing to adhere to formal specifications, established
policies,
etc. Either
way, they're likely to be fired when all is said and done.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Bingo!
-spc (The Emperor may have no clothes, but he can still behead you ... )
7:53 a.m.
It was thus said that the Great Richard Erlacher once stated:
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
Really? Please, do tell me what that lesson is.
-spc (Whose work ethic precludes dying at work)
I consider them insane, but hey, they're
still working and I'm not. So
there you have it (I've quit a job because I didn't agree with the coding
standards but that was several years ago. My current unemployment is due to
working for a completely insane boss who's goal in life seems to be to die
at work (``I had pnemonia for six weeks and did *I* take time off from
work?'' And he was back to work two days after having some heart work done)
and I took a few weeks off when I had bronchitus).
There's a lesson there, isn't there?
10:21 a.m.
----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, April 23, 2002 10:53 AM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)
Really? Please, do tell me what that lesson is.
I was referring to the fact the guys who held their noses and plowed ahead,
using what the boss wanted (he's the guy who signs the checks, after all.)
still have their jobs while you, though you're "clearly" superior in your
judgment, are not. Not everybody objects to "dying with your boots on," by
the way.
Dick
It was thus said that the Great Richard Erlacher once
stated:
>
> From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
>
> > I consider them insane, but hey, they're still working and I'm not.
So
> > there you have it (I've quit a job
because I didn't agree with the
coding
> > standards but that was several years ago.
My current unemployment is
due to
> > working for a completely insane boss
who's goal in life seems to be to
die
> > at work (``I had pnemonia for six weeks and
did *I* take time off from
> > work?'' And he was back to work two days after having some heart work
done)
and I took a few weeks off when I had bronchitus).
There's a lesson there, isn't there?
12:43 p.m.
It was thus said that the Great Richard Erlacher once stated:
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
So which way do you want it, Richard? And I quote *YOU* by the way:
It was thus said that the Great Richard Erlacher
once stated:
I was referring to the fact the guys who held their noses and plowed ahead,
using what the boss wanted (he's the guy who signs the checks, after all.)
still have their jobs while you, though you're "clearly" superior in your
judgment, are not. Not everybody objects to "dying with your boots on," by
the way. There's a lesson there, isn't there?
Really? Please, do tell me what that lesson is. No, I don't wonder. This situation can't be
blamed on the mangers either,
though, because the programmers shouldn't tolerate this.
And ...
Usually schedule and workload can be adjusted early in
the project, so if it
doesn't suit you, or, if, early in the progress of the work, you discover a
serious obstacle, that can be dealt with rationally. If you just quietly go
away, letting him plan his schedule on your acceptance of his schedule and
task loading, it's on you.
Or how about:
Perhaps the programmers should simply refuse to work
that way, rather than
abjectly refusing to adhere to formal specifications, established policies,
etc.
So what, exactly, is the lesson there? You're giving mixes messages here
Richard.
-spc (Just don't force me to die with my boots on ... )
21 Apr
21 Apr
12:55 p.m.
Most of the software in use in the UNIX world is
free. Of course
there ARE commercial packages, but...with very few exceptions, for
every commercial package there's at least one free one that does the
job as well or better. ...
Hmmm,
OK, Apache is free and "free"; but the main uses for Unix in large
organisations are products like Oracle and SAP.
Oracle may (nowadays) be effectively free for single user purposes, but it
very definitely is not for large installations. I don't think I've heard of
one large organisation using a database other than Oracle, MS SQL server, or
the IBM product.
SAP makes Oracle look inexpensive.
The _training_ costs alone for these products typically approach five
figures.
(and that is just the DBA/application programmer ... sites needing the
advanced training have even greater expenditure)
Andy
8118
days inactive
8123
days old
16 comments
6 participants
participants (6)
-
andyh＠andyh-rayleigh.freeserve.co.uk -
doc＠mdrconsult.com -
edick＠idcomm.com -
mcguire＠neurotica.com -
pechter＠pechter.dyndns.org -
spc＠conman.org