"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." > 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... > > 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). 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. OK, this random-walked really far away from linux-il. -- 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]
