> -----Original Message-----
> From: Oleg Goldshmidt [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 18, 2003 2:01 PM
> To: '[EMAIL PROTECTED]'
> Subject: Re: Fw: What's wrong with this code?
>
>
> "Tal, Shachar" <[EMAIL PROTECTED]> writes:
>
> > If I need access to code which I am not "privileged" for, I ask for
> > it, and bang, 15 seconds later I have access to it. No big
> > "fill-forms-in-three-copies-then-chase-disgruntled-IT-people" deal.
>
> This seems to me a contradiction to what you wrote earlier. To quote:
>
> "The company I work for currently does not allow engineers access to
> code they have no business reading in the first place. Of course, a
> malicious programmer can always social engineer his way into getting
> access to the code."
How is that contradiction? Does not allow != VP R&D signs approval forms.
When I need access to code X, I ask the person in charge of that for access,
and he either gives it to me or not, based on the reasons I give him.
If he doesn't, I either flog him with really long SATA cable or talk to his
boss.
>
> > The point I try to drive is, you don't need good reasons to
> > compartmentalize. You need good reasons not to.
>
> I said nothing about "compartmentalization," whatever meaning you care
> to put into the word. I remarked on the passage quoted above, saying
> that reasons to do that were few and far between.
>
> > Well, most tools do exist (e.g. source control, automated testing,
> > UML code generator) for 99.9% per cent of the companies, who deal
> > mostly with standard software engineering. The other 0.1% may
> > require exotic tools (e.g. I have no idea how to test VMWare
> > without special tools).
>
> I am guessing wildly. It seems that your notion of "standard software
> engineering" differs from mine. I suspect you assign all the different
> things I did and all the things I am doing to 0.1% of "exotic"
> activities. Dealing with VMWare does not seem exotic at all to me...
You misunderstood my example. I did not mean *using* VMWare, I meant
*testing* VMWare (as the VMWare vendor).
> > > If you know how to reach a ratio of internal to customer
> code of more
> > > than 10:1 (apart from Excel macros), and produce decent
> customer code,
> > > would you consider sharing the insights?
> >
> > You seem to either be really amazed by what I said. People,
> am I the only
> > one in the forum who thinks that most code written is production
> > code?
>
> Don't confuse between production code and customer code. Internal code
> (including all the examples you gave, which are good but few) can be
> production.
>
> There is ample anecdotal evidence of surveys done at software
> development conferences of how many programmers work on customer
> deliverables. The numbers usually quoted are in the range of 95% code
> written for internal consumption. Last time I personally was present
> when this kind of question was asked was at Go-Linux in spring. A
> speaker asked a big hall full of people who developed software for a
> living (a good portion of the audience raised hands) and then who
> wrote code sold to customers (2 or 3 hands).
I find it extremely hard to believe. I' think that the business model of the
employers of those present at that Go-Linux is skewed in a sick, sick way
(assuming open-source is still a long way from being profitable for any but
a select few).
Every single person in the my development group is developing code that is
sold to customers. Previous jobs had roughly the same percentile of
"money-bringing" people (surely all had >90% money earners).
> In every company I worked for internal scaffolding was
> done. Prototypes, demos, tons of debugging code and tools specific to
> the domain, research tools, simulators for hardware and software,
> independent implementations of different solutions only one of which
> ultimately became production, customization and fixing of existing
> software and libraries, throw-away code to try things out, you name
> it.
>
> A situation where you have tools that generate ready production code
> for you, verify it, generate automatic builds, testing, and all the
> rest of the scaffolding, sounds really exotic to me.
To tersely comment on these long paragraphs: I never worked for companies
who waste their resources writing prototypes and demos that never ended as
production code. It's not that I select my jobs that way, it just never
happened. I suspect such companies either have deep pockets to fund these
activities, or they go under very fast.
There are demos, there are prototypes, not every implementation is customer
code, I'll grant you that. But, in a system with 7GB worth of code (the
system I currently work on), with ~90% of it going to customers, there
aren't ~70GB lines of internal code.
> OK, this random-walked really far away from linux-il.
Granted. Let's take this off the list.
> --
> Oleg Goldshmidt | [EMAIL PROTECTED]
>
> =================================================================
> To unsubscribe, send mail to [EMAIL PROTECTED] with
> the word "unsubscribe" in the message body, e.g., run the command
> echo unsubscribe | mail [EMAIL PROTECTED]
>
This electronic message contains information from Verint Systems, which may
be privileged and confidential. The information is intended to be for the
use of the individual(s) or entity named above. If you are not the intended
recipient, be aware that any disclosure, copying, distribution or use of the
contents of this information is prohibited. If you have received this
electronic message in error, please notify us by replying to this email.
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
