Embedded programming usually solo? - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Embedded programming usually solo?
Quoted text here. Click to load it

You forgot handwaving.

"OK" seems to be universally understood.

Re: Embedded programming usually solo?
Quoted text here. Click to load it

My devious original point was that it is NOT socially acceptable
for native English speakers to speak bad English.  For suitable
regional variations of 'bad'.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Embedded programming usually solo?

Quoted text here. Click to load it

But which language would that be?

I read a book in recent years that made a case for English
becoming somewhat universal, not because of its superiority,
but due to it not being the native language of that hated other
group (where "hated other group" can be anybody else).

Re: Embedded programming usually solo?
snipped-for-privacy@mojaveg.iwvisp.com (Everett M. Greene) writes:

Quoted text here. Click to load it

But the problem is that English is the native language of two
widely hated countries, the UK and US.

This is a good reason to make Finnish the official world language :-)
No one will ever claim it's an imperialist language.  There are too
many "L"s though for native Japanese speakers (I want to hear one say
"illallinen", and there would be an epidemic of carpal tunnel syndrome
from having to type the long words.  Esperanto could work, but it's
far too easy.

--
Darin Johnson
    "You used to be big."
We've slightly trimmed the long signature. Click to see the full one.
Re: Embedded programming usually solo?
Quoted text here. Click to load it

The solution is simple, and minimizes disturbance. Use Canadian.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Embedded programming usually solo?

Quoted text here. Click to load it

Naw, it's too similar to French.

--
Darin Johnson
    My shoes are too tight, and I have forgotten how to dance -- Babylon 5

Re: Embedded programming usually solo?
Quoted text here. Click to load it

Eh? ;-)

--
Linux Home Automation         Neil Cherry         snipped-for-privacy@comcast.net
http://home.comcast.net/~ncherry/ (Text only)
We've slightly trimmed the long signature. Click to see the full one.
Re: Embedded programming usually solo?
Quoted text here. Click to load it

And there would be no obfuscated C contests...

Quoted text here. Click to load it

All you need is a header file containing:

#define pour for
#define ecritf printf
#define sortie exit

etc...


--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)



Re: Embedded programming usually solo?
Quoted text here. Click to load it

Oh, I don't know.  When I first moved here to Yorkshire from Australia
20 odd years ago I thought the locals spoke obfuscated English, especially
the kid who came and knocked on my front door asking something which to
this day I have no idea what!

--
Trevor Barton

Re: Embedded programming usually solo?
Quoted text here. Click to load it

Not exactly - it is a very different "understanding" for humans and
computers.
Understanding of computer is executing the code and producing a result. For
example
understanding of some code would be "0.34175".
For me (a human using this code) understanding the same code would be "it
calculates a solution of
some differential equation" - or sometimes much more, like used method and
may be a proof
of its correctness etc.

Do you see difference?

          Regards,
                               Michael



Re: Embedded programming usually solo?
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

My memory must be failing. I don't remember working for you :-)

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Embedded programming usually solo?
Quoted text here. Click to load it

There is a balance to be struck here.  In most modern companies there is
indeed a great concern with the bottom line.  That's because those who
are less concerned with the bottom line are no longer employing anyone
because they are no longer in business.  

This is particularly the case for small compnaies who can't amortize
the cost of documentation, or documentation controlling people, over
a large number of employees.  In a small company, you have to keep the
money coming in to pay the engineers, and rarely are customers willing to
pay for documentation as a direct chargeable cost.  This means that as
soon as the engineers have finished working on something and it gets
shipped, they have to move on.  Full stop (or period, depending where
you come from).  Otherwise there is nothing to pay them with.

Also there's a question of cost-effectivness.  Often after a project
is finished and some time in the field has passed, noone will visit the
code for a long time, and perhaps never.  Is it worth spending 100 hours
documenting code now that may never be revisited?  Is it worth spending
that 100 hours documenting code that may be revisited, but it'll only
take the poor sucker 50 hours later to figure out how the particular bit
of code that's causing a problem works anyway?  It's easy to look at
some old code and curse the lack of documentation when it's you that's
got to do it, but is it really costing the company more to have you do
that than it would have to document it "properly" in the first place?

As I said at the beginning, there is a balance to be struck.  At the end
of the day, someone has to pay for any documentation, and that someone
has to be the customer, and they are rarely willing to pay for code-level
documentation.  That might not be ideal, but it's the way it works.  
Anyway, look at it pragmatically.  As an engineer what would you rather
be doing, engineering or documentation?

As a case in point, we almost never write anything external to the
source code as documentation.  We use the file headers for an overview
if it's appropriate, and function header comments where appropriate
and a running commentry in the function body if that's appropriate.
We do format the comments for Doxygen, though, these days.  That way,
code documentation doesn't require any special effort, and is written
as part of the "flow of thought" as modules are created, and it's
relatively easy to keep it up to date with the actual state of the
code as things change.  It wouldn't satisfy NASA, but our customers
don't pay NASA rates and we're still in profit.

--
Trevor Barton

Re: Embedded programming usually solo?
Hi Trevor,

Quoted text here. Click to load it

Indeed, actually, every one try to reduce the (famous) "time to market".
It's easy to speed up a project if the documentation process is
not done.

Quoted text here. Click to load it

I don't agree with you on this point : it's the best way to
create unmaintainable code and buggy software :
- many globals and border effects
- tricky patches everywhere
- no logical architecture/structure

I had to port an old program made like this (10 years old),
it was a real nightmare ! Even several years after the
initial release, there were still nasty bugs hanging around
(mostly border effects).

A good initial analysis (generaly with a bit of documentation)
help a lot to produce a good architecture. Software engineering
is not just "coding" ! ("coding" is more and more often done
in the 3rd world country actually...)

Regards
Emmanuel

Re: Embedded programming usually solo?
Quoted text here. Click to load it

Well that's design, which is a different thing to documentation.
Design can be as little as a discussion between team members to
someone working on a written design and giving it to everyone else
to a multi-volume spec from the customer.  I wasn't talking about
the design process, though.

I'm talking here about documentation of the implementation, and
my point is that it's important to do that in a way that doesn't
impinge on the costs of producing the software, and also in a
way that doesn't involve engineers doing things that they have
neither the time or the temperament (sp?) to do.  Keeping it simple,
local (ie inline with the code) and automated (Doxygen) is the
only way you realistically have a chance of keeping it relevant
and up to date.


--
Trevor Barton

Re: Embedded programming usually solo?

Quoted text here. Click to load it

In my small employer, I've managed to show my bosses that the lack of
documentation was costing us my time in technical support and training,
and the sales guy wanted nice manuals he can show people to make them
feel good, so I've been let loose on a documentation project. Yay! Alas,
the sales guy is always wanting me to reword bits of it, or use pretty
fonts, or churn out millions of screenshots and diagrams to make it look
glitzy - I'm more concerned about it covering everything and being
easily readable :-/

But this is user documentation, not code documentation. Currently, I am
the code documentation; I'm always working on this software so I'm not
likely to forget much (although it is now large enough that I have to
spend time refreshing my memory when I work on parts of it that have
lain fallow for a while now...). So I don't think I'll have much luck
pressing to be allowed to write code documentation for a while - at
least, not until I look like I might want to leave the company or
anything like that...

ABS


Re: Embedded programming usually solo?
Quoted text here. Click to load it

Yeah, I was talking specifically about code documentation.  User
documentation is neither use nor ornament to the person trying to
maintain the code later (almost).  It's also something the customer
is likely to want to pay for, but if she doesn't it matters little as
far as the project implementation goes.

I was also putting more of an emphasis on single user projects, for
example systems specific to one customer.  There the choice of user
documentation is more down to the customer.  I would agree, however,
that if you are writing software to be sold to a large number of
customers there might be more reason to take the burden of user
documentation on yourself (as a company), but of course the cost
is then amortized across the entire user base.  It's all a matter
of balance, but at the end of the day it's not going to get done
if it's a net cost to the company.

--
Trevor Barton

Re: Embedded programming usually solo?

Quoted text here. Click to load it

One use of user documentation for me as a developer is that I can use it
as a spec, and feel freer to change undocumented behaviour ;-)

Quoted text here. Click to load it

I agree! I wasn't disagreeing, just giving a kind of case study of how
I'd managed to show management that some documentation was worth doing,
while some wasn't.

ABS



Re: Embedded programming usually solo?

Quoted text here. Click to load it

Weirdo.

8-)

Quoted text here. Click to load it

It's amazing how strange your own code can look after a break of 6 months or
so.

Re: Embedded programming usually solo?
Quoted text here. Click to load it

I like writing - I've co-written a book and technically edited two more
and don't plan on stopping any time soon :-)

Quoted text here. Click to load it

Yes! Until I remember what the mental model I was working with was. Code
documentation, of course, could mainly boil down to recording the mental
model, then a few extra links between the bits of the mental model and
the bits of source that implement it...

ABS


Re: Embedded programming usually solo?
           snipped-for-privacy@Xisotek.co.uk "Trevor Barton" writes:

Quoted text here. Click to load it

Creating good documentation usually has a beneficial effect on the
bottom line. This is not always immediately obvious to those that do
the accounting of such matters on a short term basis (most accountants)
but is seen when properly considered over the life of the product (the
benefits are in reduced maintenance costs).
 

[X]

Quoted text here. Click to load it

NASA and others similar clients tend to insist on sight of the document
package before you even buy the first hardware component and certainly
before you lay the first bit of production code.

I also tend to comment in the source code headers to indicate the intent
of each function and maybe the reasoning behind the approach. However, I
do not cut any code to meet the intent implied in the comments until
such time as a significant proportion of the system is commented this
way and has undergone a review. That way, when I do write the code the
requirement for each function is quite solidly thought out and is
unlikely to change too much. It is a sort of factoring of the
requirements down to sub-routine level. This is not necessarily all
top down as sometimes I find it easier to do the middle layers first.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline