On accounting and engineering.(Slightly offtopic)

On accounting and engineering.(Slightly offtopic)

[Caffeine Junky]

This post isn't specifically relevant to Ada, but rather to software
companies in general.(Or perhaps it isn't relevant, you be the judge.)

There is alot of headbanging going on between "bean counters" and
engineers in the world of software engineering. Indeed, I've encountered
this on a couple of small contract jobs I did for a local company. The
lead engineers would say "We need X, Y, and Z in order to properly
complete this assignment." and the bean counters would say "Sorry, your
going to have to settle for G and H."
Upon conversing with both the lead engineers and the bean counters over
beer, I discovered that they both wanted what was best for the company(at
least in this case) but thier perspectives were so radically different as
to make effective communication all but impossible. They both had
legitimate reasons for thier demands, hence work came to a temporary
standstill until the boss effectively mediated the conflict.

The resolution to the above conflict is immaterial here. What I'm
focusing on is the lack of the ability to communicate.

Recently a buddy of mine(a bean counter for another company) and I were
discussing this issue, heatedly at times. Until we finally realized that
the problem wasnt in our philosophy, but rather in our ability to
understand the other person. Our perceptions were so different that at
times we were using the same words, yet pouring entirely different
meanings into them(i.e. Total Cost, Maintenance, Reliability, etc..).

Hence we came up with a possible solution to the language wall(at least
as far as software development is concerned.) As part of orientation for
a company(in the tech field, but possibly other fields as well) have the
engineers take a couple short introductory courses on accounting, so as
to give the engineers a tool for effectively communicating with the bean
counters, and likewise give the bean counters a couple short introductory
courses on programming and software engineering, to reciprocate the tool.
Since they're accountants they can obviously handle the math(safe
assumption?). Likewise since they are accountants, it isnt necessary to
give them a full engineering course. But rather the goal is to enable
both parties to see in thier mind (aka understand) at least a portion of
what the other sides reasoning is.

I've recently picked up several books on accounting, and it's giving a
much better picture of how to pitch myself to the bean counters. Likewise
my pal in accounting has begun reading some introductory books on
programming and software engineering, and has a much better idea of why
the engineers make pitches that before sounded completely irrational to
him.(Stuff like purchasing rackmount servers rather than beige case
systems, and when to/when not to do in house development.)

Of course, I could just be blowing hot-air here. My professional
experience is not nearly as extensive as many in this newgroup.
Nonetheless, I seem to have hit on something that might just make my
life, and lives of others in our field, a bit less frustrating.

Now that I reflect back on it, it seems so obvious that I should have
considered it earlier. Maybe this is just a case of a newbie getting his
first professional pubes. 

So, am I stating the obvious and wasting newserver space? Have I hit upon
something worthwhile? Should I just leave the accounting to the
accountants? What are your experiences?

Any insight from the more experienced among us would be helpful.

Thanks for your patience.

St4pL3

Re: On accounting and engineering.(Slightly offtopic)

[Adrian Hoe]

Caffeine Junky wrote:

> This post isn't specifically relevant to Ada, but rather to software
> companies in general.(Or perhaps it isn't relevant, you be the judge.)
> 
> There is alot of headbanging going on between "bean counters" and
> engineers in the world of software engineering. Indeed, I've encountered
> this on a couple of small contract jobs I did for a local company. The
> lead engineers would say "We need X, Y, and Z in order to properly
> complete this assignment." and the bean counters would say "Sorry, your
> going to have to settle for G and H."
> Upon conversing with both the lead engineers and the bean counters over
> beer, I discovered that they both wanted what was best for the company(at
> least in this case) but thier perspectives were so radically different as
> to make effective communication all but impossible. They both had
> legitimate reasons for thier demands, hence work came to a temporary
> standstill until the boss effectively mediated the conflict.
> 
> The resolution to the above conflict is immaterial here. What I'm
> focusing on is the lack of the ability to communicate.
> 
> Recently a buddy of mine(a bean counter for another company) and I were
> discussing this issue, heatedly at times. Until we finally realized that
> the problem wasnt in our philosophy, but rather in our ability to
> understand the other person. Our perceptions were so different that at
> times we were using the same words, yet pouring entirely different
> meanings into them(i.e. Total Cost, Maintenance, Reliability, etc..).
> 
> Hence we came up with a possible solution to the language wall(at least
> as far as software development is concerned.) As part of orientation for
> a company(in the tech field, but possibly other fields as well) have the
> engineers take a couple short introductory courses on accounting, so as
> to give the engineers a tool for effectively communicating with the bean
> counters, and likewise give the bean counters a couple short introductory
> courses on programming and software engineering, to reciprocate the tool.
> Since they're accountants they can obviously handle the math(safe
> assumption?). Likewise since they are accountants, it isnt necessary to
> give them a full engineering course. But rather the goal is to enable
> both parties to see in thier mind (aka understand) at least a portion of
> what the other sides reasoning is.
> 
> I've recently picked up several books on accounting, and it's giving a
> much better picture of how to pitch myself to the bean counters. Likewise
> my pal in accounting has begun reading some introductory books on
> programming and software engineering, and has a much better idea of why
> the engineers make pitches that before sounded completely irrational to
> him.(Stuff like purchasing rackmount servers rather than beige case
> systems, and when to/when not to do in house development.)
> 
> Of course, I could just be blowing hot-air here. My professional
> experience is not nearly as extensive as many in this newgroup.
> Nonetheless, I seem to have hit on something that might just make my
> life, and lives of others in our field, a bit less frustrating.
> 
> Now that I reflect back on it, it seems so obvious that I should have
> considered it earlier. Maybe this is just a case of a newbie getting his
> first professional pubes. 
> 
> So, am I stating the obvious and wasting newserver space? Have I hit upon
> something worthwhile? Should I just leave the accounting to the
> accountants? What are your experiences?
> 
> Any insight from the more experienced among us would be helpful.
> 
> Thanks for your patience.
> 
> St4pL3
> 


The major issue is $$$. Accountants are more interested in RoI (Return 
of Investment), depreciation (software?) and etc. When I proposed to 
my company to switch to Ada many years ago, the first question was 
"What will be the RoI and benefits over development cost if we switch 
to Ada?"

If a company is using X at the moment and someone propose to use Y, 
cost comparison will be the first line. If Y is more expensive than X, 
why should one spend more money while X still can meet the challenge. 
But if Y is free (open source free software like gnat), why should one 
trust Y while you have got all the guarantee by paying for X. That's 
funny!

Other issues will be like the cost of training and development and 
maintenance cost which cannot be estimated as the company has not yet 
established/experienced any track records using the new tool (Ada, 
could be).

Of course, one cannot compare Ada to other programming languages as if 
rackmount servers to beige case systems. Programming language is more 
abstract and non-tangible (as per Accounting terms) compare to 
hardware. I met a stupid accountant some time ago. He set 20% 
depreciation rate to software. Imagine that?!

I like your idea about the short courses. I am going to consider this 
to be incorporated into my consulting job. If this is proven to be 
effective, I will give you a treat. ;-) Guaranteed!
-- 
type Dmitry is new Adrian;           -- Adrian Hoe
                                      -- http://adrianhoe.com
                                      -- Remove *nospam* to email

Re: On accounting and engineering.(Slightly offtopic)

[John R. Strohm]

"Adrian Hoe" <mailbox@*nospam*adrianhoe.com> wrote in message
news:3d5dc21a_2@news.tm.net.my...
> The major issue is $$$. Accountants are more interested in RoI (Return
> of Investment), depreciation (software?) and etc. When I proposed to
> my company to switch to Ada many years ago, the first question was
> "What will be the RoI and benefits over development cost if we switch
> to Ada?"

That's where you whip out a few PowerPoint charts.  Start with the one
headed "Pratt&Whitney", with the two bullets "2X increase in programmer
productivity" and "4X DECREASE in defect density".

> Other issues will be like the cost of training and development and
> maintenance cost which cannot be estimated as the company has not yet
> established/experienced any track records using the new tool (Ada,
> could be).

There, you whip out the chart, straight from AdaIC, that points out that
competent programmers typically need two weeks of training and they are up
and running in Ada.

> Of course, one cannot compare Ada to other programming languages as if
> rackmount servers to beige case systems. Programming language is more
> abstract and non-tangible (as per Accounting terms) compare to
> hardware. I met a stupid accountant some time ago. He set 20%
> depreciation rate to software. Imagine that?!

That is probably not unreasonable.  Are you going to use that same software
for more than 5 years?  Or are you going to upgrade or replace it?

Re: On accounting and engineering.(Slightly offtopic)

[Darren New]

"John R. Strohm" wrote:
> That is probably not unreasonable.  Are you going to use that same software
> for more than 5 years?  Or are you going to upgrade or replace it?

Exactly. This just goes to show that engineers often don't even understand
the most basic of accounting terms, like what "depreciation" means.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

Humility? Why would I need to show some humility?

Re: On accounting and engineering.(Slightly offtopic)

[AG]

"Darren New" <dnew@san.rr.com> wrote in message
news:3D5E7447.5E3EB4DB@san.rr.com...
> "John R. Strohm" wrote:
> > That is probably not unreasonable.  Are you going to use that same
software
> > for more than 5 years?  Or are you going to upgrade or replace it?
>
> Exactly. This just goes to show that engineers often don't even understand
> the most basic of accounting terms, like what "depreciation" means.

Except, perhaps, the programmers who wrote the accounting
packages in the first place. You don't imagine that today's
"bean counters" are doing it by hand? At least most of the time?

Re: On accounting and engineering.(Slightly offtopic)

[Adrian Hoe]

Darren New wrote:

> "John R. Strohm" wrote:
> 
>>That is probably not unreasonable.  Are you going to use that same software
>>for more than 5 years?  Or are you going to upgrade or replace it?
>>
> 
> Exactly. This just goes to show that engineers often don't even understand
> the most basic of accounting terms, like what "depreciation" means.
> 
> 


Software has either 0% or 100% depreciation.

Why 0%? Because software doesn't have wear and tear. SOme software may 
even run for 10 years or longer, like those legacy software. In fact, 
its value increases at time because of maintenance.

Why 100%? COTS like productivity software (eg. M$ Office) will become 
obsolete in 1-2 years time when new version is released. Can you sell 
it as 2nd hand??? (But it is still working)

The problem with software is that when you are still using it, it has 
value on your book. The moment you stop using it, the value becomes null.
-- 
type Dmitry is new Adrian;           -- Adrian Hoe
                                      -- http://adrianhoe.com
                                      -- Remove *nospam* to email

Re: On accounting and engineering.(Slightly offtopic)

[Darren New]

Adrian Hoe wrote:
> The problem with software is that when you are still using it, it has
> value on your book. The moment you stop using it, the value becomes null.

Which, as I said, just means you don't understand what accountants use
depreciation for.

Depreciation doesn't keep track of how much remaining value the software
has. Depreciation keeps track of how much of the money you spent to buy the
software was spent to make the money you made using that software this year.

If you spend $10K on a package that you use for 10 years, you depreciate it
$1K per year (in simple formulations), not because after 3 years the
software is only worth $7K. That's irrelevant. What's relevant is that if
you depreciated the entire package in the first year, you'd have an
inbalance in your profit vs expense calculations. Not all $10K of that
software purchase was spent in order for you to make the money from it the
first year. Depreciation has nothing, nada, zippo, zilch to do with how much
the thing you bought is still worth, and everything to do with how long you
use it.

You don't think accountants should tell engineers what software to use. Why
would you, as an engineer, think you should tell accountants how to control
the spending of money?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

Try our EbolaBurgers...
      So tender they melt in your mouth.

Re: On accounting and engineering.(Slightly offtopic)

[Adrian Hoe]

Darren New wrote:

> Adrian Hoe wrote:
> 
>>The problem with software is that when you are still using it, it has
>>value on your book. The moment you stop using it, the value becomes null.
>>
> 
> Which, as I said, just means you don't understand what accountants use
> depreciation for.
> 
> Depreciation doesn't keep track of how much remaining value the software
> has. Depreciation keeps track of how much of the money you spent to buy the
> software was spent to make the money you made using that software this year.
> 
> If you spend $10K on a package that you use for 10 years, you depreciate it
> $1K per year (in simple formulations), not because after 3 years the
> software is only worth $7K. That's irrelevant. What's relevant is that if
> you depreciated the entire package in the first year, you'd have an
> inbalance in your profit vs expense calculations. Not all $10K of that
> software purchase was spent in order for you to make the money from it the
> first year. Depreciation has nothing, nada, zippo, zilch to do with how much
> the thing you bought is still worth, and everything to do with how long you
> use it.


When you purchase a pc and a software package, you pay an amount of 
money say ($20k, $10k for hardwrae and 10k for software). The 
accountant will credit the bank/cash account but 20K does not go into 
expenses. This is not expenses. This is an asset. Credit the asset. 
Depreciation tells you how much residue value of your asset at the 
time. Hardware usually has 40% of depreciation so that the equipment 
can be fully depreciated on the book in 2.5 years. This is due to how 
fast the computer technology advances. Almost every 9-18 months will 
have new products coming. So, you will have something like:

1st year hardware = $10K
2nd year hardware = $6K
3rd year hardware = $2K
3.5rd year hardware = $0


This issue is reflected diffrently in a developer and end-user company.

For a developer, say you buy an Ada83 compiler in 1992 for $10K. But 
in 1995, Ada95 becomes the new standard and you wish to migrate to 
Ada95 and port all applications to Ada95. The moment you acquire Ada95 
compiler and stop using Ada83 in 1995, the asset value (Ada83 
compiler) becomes zero immediately. Why? Because you write it off from 
your book. This becomes an expenses. Credit Asset and debit expenses 
or depreciation. Within 1992 and a day before you acquire Ada95 in 
1995, Ada83 compiler was your asset and it was registered in your 
book. It is a different case for your Sun Workstation SPARC5 (for 
example). You purchased it in 1992 at a price of $10K (for example). 
In mid of 1995 (2.5 years), it has been fully depreciated. But if you 
continue to use it, it is still your asset and the accountant will 
re-value it at a much lower rate. This is true in the case of Ada83 
compiler if you still continue to use it even after you acquire Ada95 
compiler, but the value stays (because there is no dpreciation).


> You don't think accountants should tell engineers what software to use. Why
> would you, as an engineer, think you should tell accountants how to control
> the spending of money?
> 
> 



-- 
type Dmitry is new Adrian;           -- Adrian Hoe
                                      -- http://adrianhoe.com
                                      -- Remove *nospam* to email

Re: On accounting and engineering.(Slightly offtopic)

[Darren New]

Nothing you've said contradicts what I said. Since this no longer has
anything to do with Ada (or indeed much to do with computers at all), feel
free to continue via email if you feel you have further points to make.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

Try our EbolaBurgers...
      So tender they melt in your mouth.

Re: On accounting and engineering.(Slightly offtopic)

[Randy Brukardt]

Adrian Hoe wrote in message <3d62faa5_2@news.tm.net.my>...
...
>When you purchase a pc and a software package, you pay an amount of
>money say ($20k, $10k for hardwrae and 10k for software). The
>accountant will credit the bank/cash account but 20K does not go into
>expenses. This is not expenses. This is an asset. Credit the asset.
>Depreciation tells you how much residue value of your asset at the
>time. Hardware usually has 40% of depreciation so that the equipment
>can be fully depreciated on the book in 2.5 years. This is due to how
>fast the computer technology advances. Almost every 9-18 months will
>have new products coming. So, you will have something like:
>
>1st year hardware = $10K
>2nd year hardware = $6K
>3rd year hardware = $2K
>3.5rd year hardware = $0
>
>
>This issue is reflected diffrently in a developer and end-user company.
>
>For a developer, say you buy an Ada83 compiler in 1992 for $10K. But
>in 1995, Ada95 becomes the new standard and you wish to migrate to
>Ada95 and port all applications to Ada95. The moment you acquire Ada95
>compiler and stop using Ada83 in 1995, the asset value (Ada83
>compiler) becomes zero immediately. Why? Because you write it off from
>your book. This becomes an expenses. Credit Asset and debit expenses
>or depreciation. Within 1992 and a day before you acquire Ada95 in
>1995, Ada83 compiler was your asset and it was registered in your
>book. It is a different case for your Sun Workstation SPARC5 (for
>example). You purchased it in 1992 at a price of $10K (for example).
>In mid of 1995 (2.5 years), it has been fully depreciated. But if you
>continue to use it, it is still your asset and the accountant will
>re-value it at a much lower rate. This is true in the case of Ada83
>compiler if you still continue to use it even after you acquire Ada95
>compiler, but the value stays (because there is no dpreciation).


If you are a large company and you try that sort of accounting, you go
to jail (see Enron, Worldcom, et. al.) Hiding expenses as assets is
frowned upon.

If you are a small company and you try that sort of accounting, you
probably will end up either overpaying your taxes (expenses reduce your
income and thus your taxes, assets do not) or paying significant
penalties. (There is defined depreciation schedule for software for tax
purposes.) Some companies keep separate books for tax and 'regular'
purposes, but that appears sleazy at best.

                           Randy Brukardt.

Re: On accounting and engineering.(Slightly offtopic)

[Robert Dewar]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<um7r10d6be2cdf@corp.supernews.com>...
> Adrian Hoe wrote in message <3d62faa5_2@news.tm.net.my>...
> ...
> >When you purchase a pc and a software package, you pay an amount of
> >money say ($20k, $10k for hardwrae and 10k for software). The
> >accountant will credit the bank/cash account but 20K does not go into
> >expenses. This is not expenses. This is an asset. Credit the asset.
> >Depreciation tells you how much residue value of your asset at the
> >time. Hardware usually has 40% of depreciation so that the equipment
> >can be fully depreciated on the book in 2.5 years. This is due to how
> >fast the computer technology advances. Almost every 9-18 months will
> >have new products coming. So, you will have something like:
> >
> >1st year hardware = $10K
> >2nd year hardware = $6K
> >3rd year hardware = $2K
> >3.5rd year hardware = $0
> >
> >
> >This issue is reflected diffrently in a developer and end-user company.
> >
> >For a developer, say you buy an Ada83 compiler in 1992 for $10K. But
> >in 1995, Ada95 becomes the new standard and you wish to migrate to
> >Ada95 and port all applications to Ada95. The moment you acquire Ada95
> >compiler and stop using Ada83 in 1995, the asset value (Ada83
> >compiler) becomes zero immediately. Why? Because you write it off from
> >your book. This becomes an expenses. Credit Asset and debit expenses
> >or depreciation. Within 1992 and a day before you acquire Ada95 in
> >1995, Ada83 compiler was your asset and it was registered in your
> >book. It is a different case for your Sun Workstation SPARC5 (for
> >example). You purchased it in 1992 at a price of $10K (for example).
> >In mid of 1995 (2.5 years), it has been fully depreciated. But if you
> >continue to use it, it is still your asset and the accountant will
> >re-value it at a much lower rate. This is true in the case of Ada83
> >compiler if you still continue to use it even after you acquire Ada95
> >compiler, but the value stays (because there is no dpreciation).
> 
> 
> If you are a large company and you try that sort of accounting, you go
> to jail (see Enron, Worldcom, et. al.) Hiding expenses as assets is
> frowned upon.
> 
> If you are a small company and you try that sort of accounting, you
> probably will end up either overpaying your taxes (expenses reduce your
> income and thus your taxes, assets do not) or paying significant
> penalties. (There is defined depreciation schedule for software for tax
> purposes.) Some companies keep separate books for tax and 'regular'
> purposes, but that appears sleazy at best.
> 
>                            Randy Brukardt.

> If you are a large company and you try that sort of
> accounting, you go to jail (see Enron, Worldcom, et. al.) 
> Hiding expenses as assets is frowned upon.

Legal advice is always dubious on this newsgroup. Appallingly ignorant
and incorrect legal advice is
really annoying. Randy, please don't guess about
things you know nothing about. You obviously have
not the foggiest idea how items are categorized
as expenses or assets. Of course hardware
acquisitions are assets and not expenses. All I
can say is that I hope

  a) you have a competent accountant taking care of
     this sort of thing for you.

  b) you don't pay attention to what the accountant
     is doing (note that if you were CEO of a big
     company that would be unwise since you have to
     certify the results).

In fact the situation is exactly the opposite. Trying to
treat assets as expenses would be tax evasion. This is
indeed the opposite kind of thing from what Enron was
doing, which was an attempt to maximize profits.

I suggest that everyone leave this sort of thing to
accountants and not pay any attention to what Randy or
I or anyone else says on a newsgroup which is supposed
to attract expertise in Ada rather than in accounting.

P.S. An entertaining story from quite a while ago with my
personal taxes was that I had listed hardware and software
items that were potentially deductible. My accountant set up to
depreciate the hardware over 5 years (the quickest
allowed, since I was not a company and could not use accelerated
depreciation, which I think is what the 2.5 years mentioned earlier in
this group is about). But when it came to software, he said "Well that
stuff is all junk,
you probably couldn't use any of it, we will write that
off and treat it as expenses, my shelf is full of completely useless
software that I have purchased!"

:-)

Re: On accounting and engineering.(Slightly offtopic)

[Randy Brukardt]

Robert Dewar wrote in message
<5ee5b646.0208220201.627c534@posting.google.com>...
>"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:<um7r10d6be2cdf@corp.supernews.com>...


>> If you are a large company and you try that sort of
>> accounting, you go to jail (see Enron, Worldcom, et. al.)
>> Hiding expenses as assets is frowned upon.
>
>Legal advice is always dubious on this newsgroup. Appallingly ignorant
>and incorrect legal advice is really annoying. Randy, please don't
guess about
>things you know nothing about. You obviously have not the foggiest idea
how items are categorized
>as expenses or assets. Of course hardware  acquisitions are assets and
not expenses.

I wasn't talking about hardware at all, only his remarks about software.
He essentially said that you don't depreciate software, which is dead
wrong. And software is an asset, not an expense, in most cases.

RRS's accountants actually tried to have us assetize every software
purchase in the late 80s; there were hundreds of such purchases that
cost $19 and the like. We finally talked them into letting us expense
stuff under $100 as being immaterial. Else the tax returns and financial
reports would have been a nightmare.

My understanding is that software can only be expensed if it has no
value at the end of 12 months. Thus, subscriptions like MSDN can be
expensed; most other software has to be capitalized and depreciated.

Please, Robert, don't jump off on the deep end about *my* accounting
knowledge as soon as you misread my response. I'd have to be pretty
stupid to not learn a lot of that in 22 years of being an officer of a
corporation with many shareholders...

But I do agree on one point: see a professional if this matters to you;
don't take my word for it (or Robert's, or any other engineer on this
newsgroup).

                Randy.

Re: On accounting and engineering.(Slightly offtopic)

[Larry Kilgallen]

In article <umah6jn4fu84d0@corp.supernews.com>, "Randy Brukardt" <randy@rrsoftware.com> writes:

> My understanding is that software can only be expensed if it has no
> value at the end of 12 months. Thus, subscriptions like MSDN can be
> expensed; most other software has to be capitalized and depreciated.

My reading of the rules several years ago is that software upgrades can
be expensed.

Re: On accounting and engineering.(Slightly offtopic)

[Mark Johnson]

Caffeine Junky wrote:
> 
> [snip - background info]
> Hence we came up with a possible solution to the language wall(at least
> as far as software development is concerned.) As part of orientation for
> a company(in the tech field, but possibly other fields as well) have the
> engineers take a couple short introductory courses on accounting, so as
> to give the engineers a tool for effectively communicating with the bean
> counters, and likewise give the bean counters a couple short introductory
> courses on programming and software engineering, to reciprocate the tool.
I used to work with a group that generally did the following...
 - the first few years, a developer is given daily direction by a lead
person, gradually doing more and more complex systems. Would help to
status schedules, explain accomplishments, problems, etc.
 - at about three to five years, starts to get the responsibility of
making those plans, generating estimates, and so on. Still working
closely with a lead person, but begins to learn the lingo as part of
their regular work.
So that when they become a "lead person", they have the basic planning
and financial background that they need to lead a project (or part of a
project). It doesn't have to be a formal training session as long as you
have the right framework in place to train people as they move up in the
organization. However, I did attend a good "Management Course" which was
50/50 management techniques and "how the facility worked". The second
half did a lot to improve my insight into how the other departments
worked.

> I've recently picked up several books on accounting, and it's giving a
> much better picture of how to pitch myself to the bean counters. Likewise
> my pal in accounting has begun reading some introductory books on
> programming and software engineering, and has a much better idea of why
> the engineers make pitches that before sounded completely irrational to
> him.(Stuff like purchasing rackmount servers rather than beige case
> systems, and when to/when not to do in house development.)
> 
That is of general benefit anyway. A good software developer has insight
into more than just "Software Engineering" but on how their products are
used (e.g., software, plans, presentations). Walking a mile in the shoes
of another goes a long way to making that happen (and explains why
rotating staff through an organization to different positions makes for
stronger staff).

  --Mark

Re: On accounting and engineering.(Slightly offtopic)

[Darren New]

Mark Johnson wrote:
> That is of general benefit anyway. A good software developer has insight
> into more than just "Software Engineering" but on how their products are
> used (e.g., software, plans, presentations). 


That's generally the difference between "system analyst" and
"developer"/"programmer". Part of it is knowing enough accounting to make
business decisions also. :-)


-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

Try our EbolaBurgers...
      So tender they melt in your mouth.