Hi Oleg, > -----Original Message----- > From: Oleg Goldshmidt [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2003 10:28 AM > To: Tal, Shachar > Cc: '[EMAIL PROTECTED]'; 'Shachar Shemesh'; Guy Teverovsky > Subject: Re: Fw: What's wrong with this code? > > > "Tal, Shachar" <[EMAIL PROTECTED]> writes: > > > I have no idea what you're talking about. > > More is the pity. Let me try to explain myself in a couple of simple > sentences. To be a good software engineer, you need to read other > people's code. To develop programs efficiently, you need to show your > code to other people. A company that does not encourage these two > activities whenever possible does not utilize the full potential of > its developers (and I am being generous). IMHO, you need a very good > reason *not* to do it.
Reason below. > > Being an IBM employee, I'm sure you are aware of software systems > > that are larger than any single person's perceptional abilities. > > Working on a multi-hundred man-years software, I seldom need to > > access code for subsystems I don't develop or maintain, and even > > more seldom need to understand its inner workings. Design documents > > are usually satisfactory. > > I never said you must read and learn *all* the code developed at your > company. I only said that unless there are compelling reasons > preventing this you should be able to access as much code as > possible. What I said was generic, not IBM-specific. Rest assured, my code is being read by others and I read other people's code. But not *everybody* read my code, nor do I bother with readying everybody's code. We use a buddy system. We have teams, each is in charge of specific subsystems. Inside teams, people read other peoples' code *all* the time by definition, since we do code reviews. Outside of teams, we have knowledge transfer sessions, both at top-level design stuff and low-level code stuff. And, yes, we consult with people from other teams when the need arises and sometimes when it doesn't. But I don't really need access to all code on a regular basis. Nor can I understand most of it (under the famous 30-second test) without guidance anyway. And it would be a wise precaution to compartmentalize, just in case I have very weak passwords *and* I leave my modem and PCAnywhere (with null password) up for the weekend, in case I may want to connect to work. You seem to view compartmentalizing as a tedious process, Dilbert-style. I do not. 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. The point I try to drive is, you don't need good reasons to compartmentalize. You need good reasons not to. > > As for internal consumption vs. customer consumption - perhaps IBM > > can afford writing a lot of software for internal consumption. Most > > companies first write customer software then internal software. > > These companies must be living in a dream world where everything they > need for development actually exists before they start. I have worked > for tiny struggling startups and for multibillion dollar > multinationals > - it's not a matter of money. This was not the case in any of them, > and I have never heard of any case like that. You first create the > scaffolding, then you build. You create more scaffolding as you build. 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). > > Granted, software is written internally everywhere (test suites, > > load suites, code generators, various automation efforts, even the > > sales people need Excel macros to compute what to charge a > > customer). But not as much as written for customer consumption. > > 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? Shachar. 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]
