Re: On accounting and engineering.(Slightly offtopic)

[Adrian Hoe <mailbox@*nospam*adrianhoe.com>]

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