Do I Really Need A Supervisor?
Auntie Alias
Do I Really Need A Supervisor?
I work for a well known aerospace firm developing embeddded
Ada software for a well known fighter aircraft. I have been
developing embedded Ada software for going on ten years now,
having contributed to missile, aircraft, tank and electronic
warfare systems now fielded. Like many of you out there I have
a wide range of experience developing Ada software for a wide
variety of processors. Like most companies, my present client
integrates me into a large and deeply nested management
environment - I have two direct supervisors (one functional,
one project) who each have their supervisors (functional and
project) who each have their supervisors, who have their
supervisors, etc,etc...My question is, Do I really need
a supervisor?
It has been my observation over the years that one step above
where I work, there is little or no software development done,
i.e, my boss does mostly management "work" - going to meetings,
interfacing with other supervisors, tracking my progress. My
bosses rarely contribute anything of technical value to the
project. Most of the time, they have little or no understanding
of what it is that I am working on. Often times, they have little
or no understanding even how to do my job - sometimes they are
not even trained as software people. Too many times in my career
I have had to explain the most basic ideas of Ada programming
to my boss. (For example, I have twice had to explain to a boss
that an Ada program needs a main procedure - that it was not just
a collection of packages that somehow starts running.)
In my current assignment, I am on a team of three people, only
two of which are designing or coding. My co-worker has been
designing our project for the past 2 1/2 years but does not
know Ada. I know Ada, but I do not know the application or her
design as well. Together or singly, either of us could complete
the design, coding, testing and integration of our subsystem into
the airplane. Working together we can get it done even faster.
But our company feels that we need a supervisor. So they assign
a third person to our team - the supervisor. Our supervisor
is buried with the responsibilities of communicating and
coordinating with other managers and with the customer (another
division of our corporation). She is unable to contribute
technically to our work. Added to this supervisor, I have a
functional supervisor and my co-worker also has a separate
functional supervisor. In addition to these supervisors, my
project feels a need to have a team of supervisors to formulate
what our software development process should be. These supervisors
it turns out do not even have experience in some cases of
developing software - let alone Ada software or embedded software.
But there they are, year after year churning out directions for
us to use to develop our software by. And let there be no doubt,
some of these directions and processes are truly assinine.
And over and above these supervisors are still more supervisors.
And they all get together for frequent meetings to study how
much our company is spending developing our software. Charts,
graphs, databases and documents are generated by the thousands
to document how far along I and my co-worker have gotten in
our development efforts. None of the people gathered together
have any idea of how to do the jobs I and my co-worker do, but
there they are, tracking our progress, coordinating our efforts,
collecting metrics, deciding on schedules, estimating efforts,
determining budgets, deciding on policies. And the schedules,
budgets and estimates are always wrong! (Never even close!)
Our project suffered a major reorganization at the beginning of
the year. A new schedule was established. Within two weeks of
the new schedule being established, it was invalidated by events.
What possible good are these supervisors?
My supervisors are incapable of doing or understanding my work.
Most of the time, they do not even know what it is that I am
working on. They are incapable of giving meaningful advice or
suggestions about the design or implementation of the software.
They are totally incapable of estimating the time that it will
take for me to do my work. They are unable to forecast the cost
of doing my work. They sign my time cards every week, but in
ten years, I have never once been challenged about my actual
time spent working. Any communications they have with other
groups, with other engineers or with the customer could more
sensibly be done by me or my co-worker. They do make a lot of
design policy and scheduling decisions - and most all of them
are poor decisions based on a poor understanding of the
technology. Either me or my co-worker could have made better
decisions quicker. What possible good are these supervisors?
The task before me and my co-worker involves developing about
15,000 to 20,000 lines of Ada for an embedded controller. It is
complicated and safety critical, but it is not that big of a
deal. I wrote something very similar last year for another
client. If I had to, I could write the code at home using an
ordinary PC and a few thousand dollars worth of equipment. It
would probably take me a year of full time effort. But the way
our company works, it has so far taken about seven man-years of
effort of the software developers alone. Many more years if you
add in the supervisor overhead - all those people arguing in
their meetings about how I should do my job. Our effort will
take another two years yet - both me and my co-worker (and the
supervisor watching over us) - all because we have to develop our
software according to the "process" (#$%@& SEI !!!) designed for
us by the other supervisors. It buys us nothing; it cost us much.
What possible good are these supervisors?
I, and engineers like me and my co-worker have clearly demonstrated
that we are trustworthy, competent and capable to get complicated
military systems implemented and fielded. All this without any real
technical help from our supervisors. (In many cases, in spite of
our supervisor's "help"!) My question is, Do I really need a
supervisor?
My answer is, No. I can do my job better and faster without the
interference of a supervisor. Just tell us what you want us to
develop a software solution for and leave us alone to develop the
solution. We already know how to do the job. Get out of our way
and we will do it. Do you want to see our country field the next
fighter aircraft ahead of schedule and way under budget? Just get
rid of most of the supervisors - our country will save billions
and have better weapons as well.
Steve J. Quest
Auntie Alias wrote:
>
> My question is, Do I really need a
> supervisor?
>
> My answer is, No. I can do my job better and faster without the
> interference of a supervisor.
Sounds like YOU need to do what I did, and that was to become
self-employed! :) I like my boss, and my employees like me too. I only
pay on commission, which means good workers earn maybe 2k per week, while
bad employees starve and die. I also allow great freedom on the job.
However, I'll never again go to work for someone else. I've been
fired from every job I have ever had, usually because I piss off a
management droid. Often I ignore direct management direction, do the
right thing, my boss gets cudos for telling me to do the right thing, and
I tell the upper managers that the middle manager told me to do the wrong
thing, and I ignored him. This usually will be tolerated about 3 times,
then they find cause and fire me. I have _never_ been fired for quality
or quantity of work. I always produce way above expectation.
This is why I now work for myself. No person ever got to be rich
by working for someone else. All rich people are self-employed! You
should be too.
As for your removal of management droids from your workplace, it
may never happen. Those people are hired because they suck dick. The
bosses above them (because they lack technical acumen) need to have
someone suck up to them. This makes them feel good (the way WE feel when
we complete a project). Without ass kissers (middle management), the
top level managers would feel left out. Now for us, the lowly engineers.
We get to feel the wrath of a person who sucks dick for a living. They
take their frustrations out on US because only THAT allows them to feel
human after spending all day sucking up to their bosses. It's a chain,
and we are at the bottom.
I used to be told what to do, how to do it, and when to have it
done by. Now that I own my company, I am asked IF I WILL do something,
given wide latitude on HOW to do it, and asked when I can have it done
by. I almost have to BEG my clients to set parameters! I love it! Once
in a while I get someone who is demanding, and I just don't choose to do
their projects, so I only do the jobs I like to do. WHAT A WONDERFUL
LIFE! It ain't all peaches and cream, but it's better than being a
wage slave. Something to think about when someone who hasn't a clue
about your job TELLS YOU HOW TO DO IT every single day...............sq
(I don't like managers, unless they are intelligent. Alas, intelligence
and ass kissing skills are usually mutually exclusive. Them that can, DO
while those who can NOT, usually teach, manage, or supervise. Just be
happy that you have the academic abilities that lead you to a technical
career where you actually DO something, and MAKE something, as opposed
to a career where you play games, kiss butt, and eat stress...........)
Mike Little
I saw a saying once that helps me though similar situations:
The meetings will continue until it is determined why the work isn't getting done.
Good luck.
--
Mike Little
SwifNet, Inc.
Stuart Brooks
See "Dilbert".
All of which you speak is an infection of big business.
You are not alone. I guess I'm lucky. I will not waste my time in that
environment. Been there, done that. And yes, it can even effect small
companies. Maybe not in depth, but in practice.
--
--------------------------------------------
Stuart Brooks
Embedded Systems Engineer
Fredericksburg VA [hsbr...@crosslink.net]
Auntie Alias <anti...@earthlink.net> wrote in article
<332743...@earthlink.net>...
> Do I Really Need A Supervisor?
>
> I work for a well known aerospace firm developing embeddded
Terry Montgomery
Common sense & observation say that the self-employed spend a lot
of time on "management". The successfully self-employed generally
work very long hours. They take a lot of risks. They grossly
underbid the first few jobs. Congratulations to the survivors.
--
Terry Montgomery
mo...@pitot.dfrc.nasa.gov
My opinion in my opinion.
Steve J. Quest
Terry Montgomery wrote:
>
> Common sense & observation say that the self-employed spend a lot
> of time on "management".
True, one _should_ spend a majority of their time in managerial
duties, however, I choose NOT to, therefore I am underworked, and loving
every FREE MINUTE I have. Low pay, but lots of free time.
> The successfully self-employed generally
> work very long hours. They take a lot of risks. They grossly
> underbid the first few jobs. Congratulations to the survivors.
I have adapted this new policy. I calculate every bid down to
the penny, and when I am convinced I have the exact figure for what it
will take in money and time, I then DOUBLE BOTH FIGURES! For some odd
reason, the doubled figure is usually closer to the accurate figure for
all the jobs I've done for the past 10 years.
I don't understand this, however, this is how I bid contracts.
sq
Kardos, Botond
Hi,
I enjoyed your letters very much.
Not so much time ago I heard a cool saying (sorry for my weak english
and the inaccurate citation):
"There's a country, and there are two big companies in it.
The one invented such things like 3 digit inflation, two world wars,
corruption, financial meetings, bureaucracy, unemployment, ...
The other made the transistor, the telephon, the automobile, the
penicilin, the computer, the ECG, the light bulb, ...
Guess wich one makes the big money and which one tells the other what
to do !"
And a bit to you "Auntie Alias" ...
Your problem is very much philosophical. If you were your own
supervisor ("just tell me what to develop and it will be done"), you had
to visit such meaningless meetings, and draw such charts, etc. ... I
agree with you, I also hate when impotent bosses tell me how to do my
work. But I enjoy the success when the product is ready, and try to be
proud of it. I made it. Not my supervisors or their supervisors. I'm the
guy who can do such things.
You may work for a smaller firm, where you are closer to the
desicions, or like Steve did it, be your own boss at your own firm.
The latter may cost you a stomach ulcer and all your leisure time,
but you may earn more.
I'm still very young, I've finished last year the University, but I
work since 5 or 6 years, and I were at a couple of small fims. And I've
simply left them every time I felt, that there's no way to get rid of my
stupid boss, or the projects they've given me weren't interesting.
Finding a good small company is also hard.
So all I can say, is: I feel with you sucker engineers !
Botond
--
Kardos, Botond - at Innomed Medical Co. Ltd. in Hungary
eMail: kar...@mail.matav.hu
phone/fax: (36 1) 268-0934
Paul E. Bennett
In article <332743...@earthlink.net>
anti...@earthlink.net "Auntie Alias" writes:
> Do I Really Need A Supervisor?
>
> I work for a well known aerospace firm developing embeddded
> Ada software for a well known fighter aircraft. I have been
> developing embedded Ada software for going on ten years now,
> having contributed to missile, aircraft, tank and electronic
> warfare systems now fielded. Like many of you out there I have
> a wide range of experience developing Ada software for a wide
> variety of processors. Like most companies, my present client
> integrates me into a large and deeply nested management
> environment - I have two direct supervisors (one functional,
> one project) who each have their supervisors (functional and
> project) who each have their supervisors, who have their
> supervisors, etc,etc...My question is, Do I really need
> a supervisor?
Yes.
> It has been my observation over the years that one step above
> where I work, there is little or no software development done,
> i.e, my boss does mostly management "work" - going to meetings,
> interfacing with other supervisors, tracking my progress. My
> bosses rarely contribute anything of technical value to the
> project. Most of the time, they have little or no understanding
> of what it is that I am working on. Often times, they have little
> or no understanding even how to do my job - sometimes they are
> not even trained as software people.
They are there to manage the other people and keep them off your backs so
that you can concentrate on the task at hand.
> In my current assignment, I am on a team of three people, only
> two of which are designing or coding. My co-worker has been
> designing our project for the past 2 1/2 years but does not
> know Ada. I know Ada, but I do not know the application or her
> design as well. Together or singly, either of us could complete
> the design, coding, testing and integration of our subsystem into
> the airplane. Working together we can get it done even faster.
> But our company feels that we need a supervisor. So they assign
> a third person to our team - the supervisor. Our supervisor
> is buried with the responsibilities of communicating and
> coordinating with other managers and with the customer (another
> division of our corporation). She is unable to contribute
> technically to our work. Added to this supervisor, I have a
> functional supervisor and my co-worker also has a separate
> functional supervisor. In addition to these supervisors, my
> project feels a need to have a team of supervisors to formulate
> what our software development process should be. These supervisors
> it turns out do not even have experience in some cases of
> developing software - let alone Ada software or embedded software.
> But there they are, year after year churning out directions for
> us to use to develop our software by. And let there be no doubt,
> some of these directions and processes are truly assinine.
Sounds like the organisation has got the tree of responsibility up-side
down. Are you sure it is this way.
> And over and above these supervisors are still more supervisors.
> And they all get together for frequent meetings to study how
> much our company is spending developing our software. Charts,
> graphs, databases and documents are generated by the thousands
> to document how far along I and my co-worker have gotten in
> our development efforts. None of the people gathered together
> have any idea of how to do the jobs I and my co-worker do, but
> there they are, tracking our progress, coordinating our efforts,
> collecting metrics, deciding on schedules, estimating efforts,
> determining budgets, deciding on policies. And the schedules,
> budgets and estimates are always wrong! (Never even close!)
> Our project suffered a major reorganization at the beginning of
> the year. A new schedule was established. Within two weeks of
> the new schedule being established, it was invalidated by events.
> What possible good are these supervisors?
They are there to take the flack for these problems. You don't get it
in the neck because the project hasn't been delivered so why complain.
Additionally, they are also there to take the responsibility for failures
as, I am sure, they have to approve what you produce based on evidence of
testing of each of the modules you produce. I suspect that someone else
does the testing. Aircraft systems are Safety Critical and have to be as
correct as possible before the CAA will let them. I expect that you are not
involved in all the discussion about the hazards and risks involved in what
you do.
> My supervisors are incapable of doing or understanding my work.
> Most of the time, they do not even know what it is that I am
> working on. They are incapable of giving meaningful advice or
> suggestions about the design or implementation of the software.
> They are totally incapable of estimating the time that it will
> take for me to do my work.
Are you any better at estimating than they are?. Do you have to provide
your own assessment for your own efforts and if so are you always right?.
> They are unable to forecast the cost
> of doing my work. They sign my time cards every week, but in
> ten years, I have never once been challenged about my actual
> time spent working. Any communications they have with other
> groups, with other engineers or with the customer could more
> sensibly be done by me or my co-worker. They do make a lot of
> design policy and scheduling decisions - and most all of them
> are poor decisions based on a poor understanding of the
> technology. Either me or my co-worker could have made better
> decisions quicker. What possible good are these supervisors?
Are you sure you want the flack?. Sounds like you may be angling for a
position on the management team yourself.
> The task before me and my co-worker involves developing about
> 15,000 to 20,000 lines of Ada for an embedded controller. It is
> complicated and safety critical, but it is not that big of a
> deal. I wrote something very similar last year for another
> client. If I had to, I could write the code at home using an
> ordinary PC and a few thousand dollars worth of equipment. It
> would probably take me a year of full time effort. But the way
> our company works, it has so far taken about seven man-years of
> effort of the software developers alone. Many more years if you
> add in the supervisor overhead - all those people arguing in
> their meetings about how I should do my job. Our effort will
> take another two years yet - both me and my co-worker (and the
> supervisor watching over us) - all because we have to develop our
> software according to the "process" (#$%@& SEI !!!) designed for
> us by the other supervisors. It buys us nothing; it cost us much.
> What possible good are these supervisors?
If your company's process is wrong, then it needs fixing. However, is
it wrong?. The extra time may be deliberately in the system to ensure that
a properly documented audit trail is created. This ultimately gives the CAA
the confidence that your company has followed the best possible practice
and has given due consideration to all the hazards and risks involved in
the project and have sufficient documented reasons for adopting certain
approaches. You probably do not know the outcome of the effects your
software will have on certain parts of the hardware.
> I, and engineers like me and my co-worker have clearly demonstrated
> that we are trustworthy, competent and capable to get complicated
> military systems implemented and fielded. All this without any real
> technical help from our supervisors. (In many cases, in spite of
> our supervisor's "help"!) My question is, Do I really need a
> supervisor?
Even military aircraft have to be safe in the air. So yes you still need a
supervisor. However, try voicing your concerns over the problems of the
procedures you are being asked to work to andbe ready with suggestions for
improvement of the process that will still comply with the requirements of
the military standards that you are working to. For my own company, involved
in Rail, Road and Marine Public Transport Support Systems, I distilled out
the essential requirements of Def-Std 00-56 and moulded our system design
procedures to that. It has become a very simple to operate procedure and
provides all of the required audit information throughout all stages of the
design and manufacturing process. Seek simplicity to build complex structures
upon.
--
Paul E. Bennett <p...@transcontech.co.uk>
Transport Control Technology Ltd.
+44 (0)117-9499861
Going Forth Safely
anti...@earthlink.net
Paul Bennett responded:
> They are there to manage the other people and keep them off your backs so
> that you can concentrate on the task at hand.
As I said, I could do that better and faster.
> Sounds like the organisation has got the tree of responsibility up-side
> down. Are you sure it is this way.
Yep, I'm there everyday. My client is nuts. And he builds airplanes
for her majesty's fine R.A.F.
>
> They are there to take the flack for these problems. You don't get it
> in the neck because the project hasn't been delivered so why complain.
> Additionally, they are also there to take the responsibility for failures
> as, I am sure, they have to approve what you produce based on evidence of
> testing of each of the modules you produce. I suspect that someone else
> does the testing. Aircraft systems are Safety Critical and have to be as
> correct as possible before the CAA will let them. I expect that you are not
> involved in all the discussion about the hazards and risks involved in what
> you do.
I do the testing. Someone else checks the boxes and takes credit for it,
but
I am the one who figures out how to test the stuff I have coded. I know
what
is involved. The ones who give the flack are supervisors too. Get rid of
the pair of useless supervisors and let me get on with my work.
> Are you any better at estimating than they are?.
The point is NO ONE can meaningfully estimate the time it will take to
solve a software coding problem. Not me, not you, not anyone. I have
never seen a software schedule that even came close to being right. I
often
play a joke on people - at the beginning of the project I save a copy of
the current schedule. A year or so late, I pin it up on the wall. It is
great fun to watch people come by, look at it, scratch their heads and
wonder why it almost looks right, it's just that it is off now by a
year.
Wayland Sothcott
Yes, this is a typical senario, you are trying to do the right thing and
all the managers are doing is making it harder. The usual aproach is to try
to get them to understand but don't try too hard else you will lose your
job. Then where you can, do it right. It may be important to remember that
being seen to do something right is as important as meeting deadlines.
People have to have their input.
I had a client who wanted pseudo code before actual coding. Unfortunatly
their idea of pseudo code looked almost but not quite exactly like the
finished source code would. So I was being asked to write the program twice
but with out the benifit of incremental development and testing the first
time. I just wrote the program in 'C' in the normal way and when she was
not looking then edited it a bit and told her it was high quality pseudo
code.
I now have my own company and can easily cope with the amount of work and
money I get.
Wayland.
David R Brooks
"Wayland Sothcott" <soth...@sothcott.demon.co.uk> wrote:
[snip]
:
:I had a client who wanted pseudo code before actual coding. Unfortunatly
:their idea of pseudo code looked almost but not quite exactly like the
:finished source code would. So I was being asked to write the program twice
:but with out the benifit of incremental development and testing the first
:time. I just wrote the program in 'C' in the normal way and when she was
:not looking then edited it a bit and told her it was high quality pseudo
:code.
:
This rings a bell for me also. Recently, I was asked to write code
for a client who explicitly forbade the use of "C" (don't ask me why):
they wanted Assembler. However, they also wanted pseudocode or
flowcharts. I was only half-joking when I offered to write it in "C",
label the source files as "pseudocode", and then give them the
compiler output as the Assembler version.
-- Dave Brooks <http://www.iinet.net.au/~daveb>
PGP public key via <http://www.iinet.net.au/~daveb/crypto.html>, or servers
"From" line rigged to foil spambots: daveb <at> iinet.net.au
Dave Baldwin
David R Brooks (da...@iinet.net.au_spam_trap) wrote:
: "Wayland Sothcott" <soth...@sothcott.demon.co.uk> wrote:
: :I had a client who wanted pseudo code before actual coding. Unfortunatly
: :their idea of pseudo code looked almost but not quite exactly like the
: :finished source code would. So I was being asked to write the program twice
: :but with out the benifit of incremental development and testing the first
: :time. I just wrote the program in 'C' in the normal way and when she was
: :not looking then edited it a bit and told her it was high quality pseudo
: :code.
: :
: This rings a bell for me also. Recently, I was asked to write code
: for a client who explicitly forbade the use of "C" (don't ask me why):
: they wanted Assembler. However, they also wanted pseudocode or
: flowcharts. I was only half-joking when I offered to write it in "C",
: label the source files as "pseudocode", and then give them the
: compiler output as the Assembler version.
These 'managers' probably had a 'bad' experience with someone coding in
'C' that screwed up a project. I'm sure they didn't know anything about
software development themselves. I had a manager that wanted me to write
code for a custom Z80 embedded system in Pascal 'because it was so easy to
put up pretty screens' on his Mac. He seemed to think that I could type
in the code on the Mac and have it magically operate on the Z80.
--
-=-=-=-=-=-=-=-=-=-=-=- Check out DIBs and TCJ -=-=-=-=-=-=-=-=-=-=-=-=-
Dave Baldwin: dib...@netcom.com | The Computer Journal 1(800)424-8825
DIBs Electronic Design | Home page "http://www.psyber.com/~tcj/"
Voice : (916) 722-3877 | Hands-on hardware and software
TCJ/DIBs BBS: (916) 722-5799 | TCJ/DIBs FAX: (916) 722-7480
-=-=-=-=-=-=- @#$%^&* I can't even quote myself! Oh,well. -=-=-=-=-=-=-
Paul E. Bennett
In article <3328AA...@earthlink.net> anti...@earthlink.net writes:
> Paul Bennett responded:
>
> > They are there to manage the other people and keep them off your backs so
> > that you can concentrate on the task at hand.
>
> As I said, I could do that better and faster.
I always find that keeping other people off the backs of those doing the
real work was always beneficial, especially when deadlines are tight.
> > Sounds like the organisation has got the tree of responsibility up-side
> > down. Are you sure it is this way.
>
> Yep, I'm there everyday. My client is nuts. And he builds airplanes
> for her majesty's fine R.A.F.
In which case I would suggest that soemone re-reads Def-Std 00-56 again and
applies a "Systems" approach to the whole issue of project management based
on the simple, but effective, essence of that standard.
> > They are there to take the flack for these problems. You don't get it
> > in the neck because the project hasn't been delivered so why complain.
> > Additionally, they are also there to take the responsibility for failures
> > as, I am sure, they have to approve what you produce based on evidence of
> > testing of each of the modules you produce. I suspect that someone else
> > does the testing. Aircraft systems are Safety Critical and have to be as
> > correct as possible before the CAA will let them. I expect that you are not
> > involved in all the discussion about the hazards and risks involved in what
> > you do.
>
> I do the testing. Someone else checks the boxes and takes credit for it,
> but I am the one who figures out how to test the stuff I have coded. I know
> what is involved. The ones who give the flack are supervisors too. Get rid
> of the pair of useless supervisors and let me get on with my work.
You mean you do some of the testing. I feel certain that someone else will
test the integrated unit out in a more formal scenario.
> > Are you any better at estimating than they are?.
>
> The point is NO ONE can meaningfully estimate the time it will take to
> solve a software coding problem. Not me, not you, not anyone. I have
> never seen a software schedule that even came close to being right. I
> often
> play a joke on people - at the beginning of the project I save a copy of
> the current schedule. A year or so late, I pin it up on the wall. It is
> great fun to watch people come by, look at it, scratch their heads and
> wonder why it almost looks right, it's just that it is off now by a
> year.
Project estimation seems to be handled differently in most organisations I
deal with. For my own company I get it right and deliver to issue 1 of the
programme about 60% to 75% of the time. I make a great deal of use of goal
based planning methods based on estaimation using Function Point Analysis.
Where we deliver to later issues of the programme is where the clients have
changed the specification and have accepted the consequential risks to the
programme.
Mark Hahn
In article <01bc30d3$a2990020$325b989e@smokey>,
"Wayland Sothcott" <soth...@sothcott.demon.co.uk> wrote:
>I now have my own company and can easily cope with the amount of work and
>money I get.
>
>Wayland.
Well there you go. My favorite bumper sticker reads:
"I love my job. I love my boss. I'm self employed."
It's plastered on the bumper of my truck.
MRH
Steve J. Quest
> : I just wrote the program in 'C' in the normal way and when she was
> :not looking then edited it a bit and told her it was high quality pseudo
> :code.
> :
> This rings a bell for me also. Recently, I was asked to write code
> for a client who explicitly forbade the use of "C" (don't ask me why):
> they wanted Assembler. However, they also wanted pseudocode or
> flowcharts. I was only half-joking when I offered to write it in "C",
> label the source files as "pseudocode", and then give them the
> compiler output as the Assembler version.
A little more devious, but since most "clients" are clueless, you
could always write it in C, label that your pseudo-code, take the object
HEX code, run it through a disassembler, and call that your assembler
code. Perhaps they wouldn't know the difference.
When my clients demand that I give them the source to a program
that I don't feel they fully own (as in I didn't get paid what I think
it was worth), I always give them disassembled "assembler source". So
far, nobody has complained, and I've only given them useless junk that
any hacker could have dumped from the Eprom himself................sq
(this works out well, because sooner or later they are going to need an
update, and without commented source, most other embedded programmers
would decline the job. Given a second shot, I can usually make up for
my previous losses by jacking up the price on the revision software, as
they NOW know that nobody, save for myself, will even ACCEPT the job!
Devious as this sounds, it does work, and is a win-win situation.......)
jim granville
> :their idea of pseudo code looked almost but not quite exactly like the
> :finished source code would. So I was being asked to write the program twice
> :but with out the benifit of incremental development and testing the first
> :not looking then edited it a bit and told her it was high quality pseudo
> :code.
> :
> This rings a bell for me also. Recently, I was asked to write code
> for a client who explicitly forbade the use of "C" (don't ask me why):
> they wanted Assembler. However, they also wanted pseudocode or
> flowcharts. I was only half-joking when I offered to write it in "C",
> label the source files as "pseudocode", and then give them the
> compiler output as the Assembler version.
>
text language, like Modula-2
or IEC1131-ST (etc), then the code is both 'supervisor readable', and
incrementally testable.
( and easier to maintain .. )
Some compilers also output ASM source with the HLL source as comments.
So whilst David was half-joking with C, I have actually seen this done
with Modula-2.
( one instance was to provide C Callable libraries, in this case, the
main source is kept, not discarded )
In a similar vein, I have also seen CAD customers specify DXF archives
of drawings, even if that
format was not (easily) revisable.
For those concerned with compiler revisions changing code operation, we
suggest the Ada approach,
of making the SOURCE, and the Compiler used, part of the one project,
and saving ALL this to a floppy
( this is often the thrust of some of the management directives
mentioned above )
jim.
--
======= Manufacturers of Serious Design Tools for uC and PLD =========
= Optimising Modula-2 Structured Text compilers for ALL 80X51 variants
= for more info, Email : Desig...@xtra.co.nz Subject : c51Tools
Darrick West
> When my clients demand that I give them the source to a program
> that I don't feel they fully own (as in I didn't get paid what I think
> it was worth), I always give them disassembled "assembler source". So
> far, nobody has complained, and I've only given them useless junk that
> any hacker could have dumped from the Eprom himself................sq
> (this works out well, because sooner or later they are going to need an
> update, and without commented source, most other embedded programmers
> would decline the job. Given a second shot, I can usually make up for
> my previous losses by jacking up the price on the revision software, as
> they NOW know that nobody, save for myself, will even ACCEPT the job!
> Devious as this sounds, it does work, and is a win-win situation.......)
>
I hope they don't know about using newsgroups. :-{)
Steve J. Quest
Trust me, so far, the offending ones haven't the ability to ever
see these posts. The usenet has a somewhat effective filter, you have
to be smart enough to know how to use a newsreader, know how to select
the groups you want, and what to do once you've gotten this far.
I think I'm pretty safe from the offending parties. As for the
clients who are _cool_, they already know I'm the Howard Stern of the
Usenet, and are ok with that. I'm only saying what other people are
thinking and too afraid to say. Maybe I'm only doing what other people
think of doing but are too afraid to try!
Hell, one of my clients couldn't understand the concept of
shareware verses licensed software NO MATTER HOW HARD I TRIED, I just
couldn't seem to explain why they didn't own the rights to shareware
and why I was providing it to them for free and why if they WANTED to
register it, they could send money to wherever and do it. :-/ Let's
not even get into my attempting to explain E-mail.................sq
(let me remind everyone, a cool client, one who doesn't cheat me, jerk
me around, and sticks to the contract as agreed WITHOUT using high
pressure lawyers to get me to back down, will always get a good deal
with me. Just ask anyone who's done business with me who's cool. For
some reason, some companies feel they simply MUST rip-off everyone they
do business with, at least a little bit. That's just not cool. By the
way, it's hard to pull the wool over the eyes of a cool client, they'd
just laugh at printouts of disassembler produced source..............)
David R Brooks
jim granville <Jim.Gr...@xtra.co.nz> wrote:
[snip]
: For those concerned with compiler revisions changing code operation, we
:suggest the Ada approach,
:of making the SOURCE, and the Compiler used, part of the one project,
:and saving ALL this to a floppy
:( this is often the thrust of some of the management directives
:mentioned above )
Hmm, "a floppy" ? What compiler do you use? With most current
compiler suites, "a CD" would be nearer the mark :-)
Of course that's entirely feasible, though I don't know what the
compiler vendor's anti-piracy unit would think.
Guy Macon
> When my clients demand that I give them the source to a program
> that I don't feel they fully own (as in I didn't get paid what I think
> it was worth), I always give them disassembled "assembler source".
I do hope you also assemble it and do a file compare on the results.
If it doesn't make the same binary, it you aren't really giving them
"source" code. (Some disassemblers *do* make mistakes!)
That being said, I suppose that you are looking for the absolute
worst disassembler around...
I remember in the old Commodore 64 days, a program that took Basic
source and:
Removed all comments
Replaced all constants with variables
assigned all variables random names
put in extra gotos and scrambled the code
put in extra variables
changed the original variables in lines of code that never executed
because the gotos jumped around it
changed the extra variables
made conditional jumps on both kinds of variables
put multiple statements on a line
It still ran, but try understanding it!
Steve J. Quest
Guy Macon wrote:
>
> > When my clients demand that I give them the source to a program
> > that I don't feel they fully own (as in I didn't get paid what I think
> > it was worth), I always give them disassembled "assembler source".
>
> I do hope you also assemble it and do a file compare on the results.
> If it doesn't make the same binary, it you aren't really giving them
> "source" code. (Some disassemblers *do* make mistakes!)
What difference does it make? Disassembly of 8k or more of code,
making instruction disassembly of text strings is junk. However, the
few times I've assembled this useless disassembly source, it recreated
a bit for bit accurate object hexfile that compared to the original.
>
> That being said, I suppose that you are looking for the absolute
> worst disassembler around...
You got it! Actually, it doesn't matter, something to printout
and hand to the demanding yet clueless.
sq