<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_02_12_2329252</id>
	<title>Learning and Maintaining a Large Inherited Codebase?</title>
	<author>timothy</author>
	<datestamp>1265976540000</datestamp>
	<htmltext>An anonymous reader writes <i>"A couple of times in my career, I've inherited a fairly large (30-40 thousand lines) collection of code. The original authors knew it because they wrote it; I didn't, and I don't. I spend a huge amount of time finding the right place to make a change, far more than I do changing anything. How would you learn such a big hunk of code? And how discouraged should I be that I can't seem to 'get' this code as well as the original developers?"</i></htmltext>
<tokenext>An anonymous reader writes " A couple of times in my career , I 've inherited a fairly large ( 30-40 thousand lines ) collection of code .
The original authors knew it because they wrote it ; I did n't , and I do n't .
I spend a huge amount of time finding the right place to make a change , far more than I do changing anything .
How would you learn such a big hunk of code ?
And how discouraged should I be that I ca n't seem to 'get ' this code as well as the original developers ?
"</tokentext>
<sentencetext>An anonymous reader writes "A couple of times in my career, I've inherited a fairly large (30-40 thousand lines) collection of code.
The original authors knew it because they wrote it; I didn't, and I don't.
I spend a huge amount of time finding the right place to make a change, far more than I do changing anything.
How would you learn such a big hunk of code?
And how discouraged should I be that I can't seem to 'get' this code as well as the original developers?
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124476</id>
	<title>Re:Not at all.</title>
	<author>Tablizer</author>
	<datestamp>1265997720000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p>I find that if the other programmer wrote it in such a way where it's too complex for me to follow, I'm not the one who's a moron.</p></div></blockquote><p>But YOU get the blame, which is the problem. This kind of thing happened to me recently when I inherited a big pile of MS-Access code with variables like A34 and 300 objects (tables, reports, queries, etc.). I went from an "excellent" rating to a "C" rating on my evaluation because they wanted quick turnaround. I <b>felt like the victim of a hit-and-run</b>. I'm not the one who did the crime, yet I'm the one with the black eye and a missing wallet. The Pasta Mugger did a number on me.</p><p>At least with text source code you can find or write variable, function, and command indexers/profilers to help one see the structure, find definitions, and browse relationships. Not so easy to do that with MS-Access with all it's proprietary binary crap. I found a way to extract some of the info, but it looks different from how you'd see it inside MS-Access so it's hard to relate to. Gotta love MS.</p></div>
	</htmltext>
<tokenext>I find that if the other programmer wrote it in such a way where it 's too complex for me to follow , I 'm not the one who 's a moron.But YOU get the blame , which is the problem .
This kind of thing happened to me recently when I inherited a big pile of MS-Access code with variables like A34 and 300 objects ( tables , reports , queries , etc. ) .
I went from an " excellent " rating to a " C " rating on my evaluation because they wanted quick turnaround .
I felt like the victim of a hit-and-run .
I 'm not the one who did the crime , yet I 'm the one with the black eye and a missing wallet .
The Pasta Mugger did a number on me.At least with text source code you can find or write variable , function , and command indexers/profilers to help one see the structure , find definitions , and browse relationships .
Not so easy to do that with MS-Access with all it 's proprietary binary crap .
I found a way to extract some of the info , but it looks different from how you 'd see it inside MS-Access so it 's hard to relate to .
Got ta love MS .</tokentext>
<sentencetext>I find that if the other programmer wrote it in such a way where it's too complex for me to follow, I'm not the one who's a moron.But YOU get the blame, which is the problem.
This kind of thing happened to me recently when I inherited a big pile of MS-Access code with variables like A34 and 300 objects (tables, reports, queries, etc.).
I went from an "excellent" rating to a "C" rating on my evaluation because they wanted quick turnaround.
I felt like the victim of a hit-and-run.
I'm not the one who did the crime, yet I'm the one with the black eye and a missing wallet.
The Pasta Mugger did a number on me.At least with text source code you can find or write variable, function, and command indexers/profilers to help one see the structure, find definitions, and browse relationships.
Not so easy to do that with MS-Access with all it's proprietary binary crap.
I found a way to extract some of the info, but it looks different from how you'd see it inside MS-Access so it's hard to relate to.
Gotta love MS.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122286</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124790</id>
	<title>report from toronto</title>
	<author>The Abused Developer</author>
	<datestamp>1266001560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>... this is the norm here in the last 7/8 years or so. doin' it differently - unit test, good design &amp; practices, honesty, long term planning etc. - are the best strategies to get you bumped out of the project.</htmltext>
<tokenext>... this is the norm here in the last 7/8 years or so .
doin ' it differently - unit test , good design &amp; practices , honesty , long term planning etc .
- are the best strategies to get you bumped out of the project .</tokentext>
<sentencetext>... this is the norm here in the last 7/8 years or so.
doin' it differently - unit test, good design &amp; practices, honesty, long term planning etc.
- are the best strategies to get you bumped out of the project.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122276</id>
	<title>Hunt down the original developer</title>
	<author>Anonymous</author>
	<datestamp>1265980560000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p>(And then shoot him.)</p></htmltext>
<tokenext>( And then shoot him .
)</tokentext>
<sentencetext>(And then shoot him.
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123438</id>
	<title>lxr</title>
	<author>Anonymous</author>
	<datestamp>1265987520000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I use a program called lxr or linux cross reference.  I even extended it for myself to handle embedded sql code.  And because it runs on a web server it allows a whole team to browse the code.</p></htmltext>
<tokenext>I use a program called lxr or linux cross reference .
I even extended it for myself to handle embedded sql code .
And because it runs on a web server it allows a whole team to browse the code .</tokentext>
<sentencetext>I use a program called lxr or linux cross reference.
I even extended it for myself to handle embedded sql code.
And because it runs on a web server it allows a whole team to browse the code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125094</id>
	<title>Learning requires a quiet environment</title>
	<author>kobol</author>
	<datestamp>1266092160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>When I inherit such a monster I just start studying it. Too bad the environment of today's open plan office doesn't allow concentration necessary to learn code. This will doom our planet in a hundred years. If only women in the office could be required to shut up for at least 20 minutes out of every hour.</htmltext>
<tokenext>When I inherit such a monster I just start studying it .
Too bad the environment of today 's open plan office does n't allow concentration necessary to learn code .
This will doom our planet in a hundred years .
If only women in the office could be required to shut up for at least 20 minutes out of every hour .</tokentext>
<sentencetext>When I inherit such a monster I just start studying it.
Too bad the environment of today's open plan office doesn't allow concentration necessary to learn code.
This will doom our planet in a hundred years.
If only women in the office could be required to shut up for at least 20 minutes out of every hour.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126902</id>
	<title>A suggestion</title>
	<author>Uzik2</author>
	<datestamp>1266076080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This will kill two birds with one stone. Write unit tests for the codebase. You will learn the code and learn what it's supposed to do well while you're doing it. Further you'll be in a better position to make changes without breaking the existing functionality.</htmltext>
<tokenext>This will kill two birds with one stone .
Write unit tests for the codebase .
You will learn the code and learn what it 's supposed to do well while you 're doing it .
Further you 'll be in a better position to make changes without breaking the existing functionality .</tokentext>
<sentencetext>This will kill two birds with one stone.
Write unit tests for the codebase.
You will learn the code and learn what it's supposed to do well while you're doing it.
Further you'll be in a better position to make changes without breaking the existing functionality.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125276</id>
	<title>break the code</title>
	<author>Anonymous</author>
	<datestamp>1266052080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>break the code<nobr> <wbr></nobr>:-)</p><p>it's the same as dismantling your dad's radio/car/computer to see what's inside and how it works and re-assembling it , only to find out there is is still one piece left</p></htmltext>
<tokenext>break the code : - ) it 's the same as dismantling your dad 's radio/car/computer to see what 's inside and how it works and re-assembling it , only to find out there is is still one piece left</tokentext>
<sentencetext>break the code :-)it's the same as dismantling your dad's radio/car/computer to see what's inside and how it works and re-assembling it , only to find out there is is still one piece left</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122286</id>
	<title>Not at all.</title>
	<author>Anonymous</author>
	<datestamp>1265980620000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext>I find that if the other programmer wrote it in such a way where it's too complex for me to follow, I'm not the one who's a moron.</htmltext>
<tokenext>I find that if the other programmer wrote it in such a way where it 's too complex for me to follow , I 'm not the one who 's a moron .</tokentext>
<sentencetext>I find that if the other programmer wrote it in such a way where it's too complex for me to follow, I'm not the one who's a moron.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125410</id>
	<title>Re:That's small</title>
	<author>Anonymous</author>
	<datestamp>1266055020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I agree with you on the size definitions.  I always felt the same way.  But since I quit being a programmer I've been working on my own project.  Because I have no one to answer to but myself I can polish the code to whatever level I want.  I have found that with careful design I can pack a surprisingly large amount of functionality in less than 10K lines of code.  This is small enough to be called a toy project, but it seems that the careful crafting of code is more interesting than the larger scale projects to me.  When I optimize my code for readability I find that it almost invariably leads to designs with very small amounts of code.  The more I work on it, the smaller (and easier to work with) it becomes.  If you have spare time for a side project, I highly recommend trying it out for yourself.</p></htmltext>
<tokenext>I agree with you on the size definitions .
I always felt the same way .
But since I quit being a programmer I 've been working on my own project .
Because I have no one to answer to but myself I can polish the code to whatever level I want .
I have found that with careful design I can pack a surprisingly large amount of functionality in less than 10K lines of code .
This is small enough to be called a toy project , but it seems that the careful crafting of code is more interesting than the larger scale projects to me .
When I optimize my code for readability I find that it almost invariably leads to designs with very small amounts of code .
The more I work on it , the smaller ( and easier to work with ) it becomes .
If you have spare time for a side project , I highly recommend trying it out for yourself .</tokentext>
<sentencetext>I agree with you on the size definitions.
I always felt the same way.
But since I quit being a programmer I've been working on my own project.
Because I have no one to answer to but myself I can polish the code to whatever level I want.
I have found that with careful design I can pack a surprisingly large amount of functionality in less than 10K lines of code.
This is small enough to be called a toy project, but it seems that the careful crafting of code is more interesting than the larger scale projects to me.
When I optimize my code for readability I find that it almost invariably leads to designs with very small amounts of code.
The more I work on it, the smaller (and easier to work with) it becomes.
If you have spare time for a side project, I highly recommend trying it out for yourself.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128466</id>
	<title>Re:Use it</title>
	<author>Jack9</author>
	<datestamp>1266087960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>// The display name should be the fullname<br>screen.displayName = user.firstName + user.lastName;</p></div></blockquote><p>Later, if the fullname becomes user.firstName + user.middleName + user.lastName, and there is no unit test that fails, there should at least be a comment.</p><p>If you want to communicate context, comments and/or unit tests are how to do it. If you want to ask the question "should I?" then someone else reading the code will ask "why didn't they?" or "what were they thinking?", so comment comment comment. In the end, you want someone reading the code to say "they just didn't do X, they did Y" and the reasoning will be clear that they original author either coded it fundamentally wrong from the beginning (unlikely) or that requirements/dependencies have changed.</p></div>
	</htmltext>
<tokenext>// The display name should be the fullnamescreen.displayName = user.firstName + user.lastName ; Later , if the fullname becomes user.firstName + user.middleName + user.lastName , and there is no unit test that fails , there should at least be a comment.If you want to communicate context , comments and/or unit tests are how to do it .
If you want to ask the question " should I ?
" then someone else reading the code will ask " why did n't they ?
" or " what were they thinking ?
" , so comment comment comment .
In the end , you want someone reading the code to say " they just did n't do X , they did Y " and the reasoning will be clear that they original author either coded it fundamentally wrong from the beginning ( unlikely ) or that requirements/dependencies have changed .</tokentext>
<sentencetext>// The display name should be the fullnamescreen.displayName = user.firstName + user.lastName;Later, if the fullname becomes user.firstName + user.middleName + user.lastName, and there is no unit test that fails, there should at least be a comment.If you want to communicate context, comments and/or unit tests are how to do it.
If you want to ask the question "should I?
" then someone else reading the code will ask "why didn't they?
" or "what were they thinking?
", so comment comment comment.
In the end, you want someone reading the code to say "they just didn't do X, they did Y" and the reasoning will be clear that they original author either coded it fundamentally wrong from the beginning (unlikely) or that requirements/dependencies have changed.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123230</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126356</id>
	<title>Re:Not lots of code</title>
	<author>Anonymous</author>
	<datestamp>1266070680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"First of all, 30-40,000 lines of code is not lots of code."</p><p>Agreed. Especially if it's all in one file.</p></htmltext>
<tokenext>" First of all , 30-40,000 lines of code is not lots of code. " Agreed .
Especially if it 's all in one file .</tokentext>
<sentencetext>"First of all, 30-40,000 lines of code is not lots of code."Agreed.
Especially if it's all in one file.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128240</id>
	<title>Re:Not lots of code</title>
	<author>ztransform</author>
	<datestamp>1266086340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>To start, use a good programming editor/environment (Xcode, Vslick, Visual Studio, etc.) that gives you the ability to easily go to definition or references to variables, functions, structs and such.</p></div><p>I went and bought a 24 inch flat screen monitor with my own money and brought it into work.

</p><p>If I couldn't have 3 editor windows open side-by-side I would not be able to perform the maintenance required.

</p><p>I use one editor for the code I'm working on. One editor for the code I'm working from. One editor to look at the file being processed. Sometimes I split my editor windows for more references: sometimes I need to look at different parts of the same file, sometimes I have to view a configuration file for interpreting the data file the script will interpret.</p></div>
	</htmltext>
<tokenext>To start , use a good programming editor/environment ( Xcode , Vslick , Visual Studio , etc .
) that gives you the ability to easily go to definition or references to variables , functions , structs and such.I went and bought a 24 inch flat screen monitor with my own money and brought it into work .
If I could n't have 3 editor windows open side-by-side I would not be able to perform the maintenance required .
I use one editor for the code I 'm working on .
One editor for the code I 'm working from .
One editor to look at the file being processed .
Sometimes I split my editor windows for more references : sometimes I need to look at different parts of the same file , sometimes I have to view a configuration file for interpreting the data file the script will interpret .</tokentext>
<sentencetext>To start, use a good programming editor/environment (Xcode, Vslick, Visual Studio, etc.
) that gives you the ability to easily go to definition or references to variables, functions, structs and such.I went and bought a 24 inch flat screen monitor with my own money and brought it into work.
If I couldn't have 3 editor windows open side-by-side I would not be able to perform the maintenance required.
I use one editor for the code I'm working on.
One editor for the code I'm working from.
One editor to look at the file being processed.
Sometimes I split my editor windows for more references: sometimes I need to look at different parts of the same file, sometimes I have to view a configuration file for interpreting the data file the script will interpret.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122316</id>
	<title>30-40kloc is not large</title>
	<author>aachrisg</author>
	<datestamp>1265980740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I wouldn't try too hard with a codebase as small as 30-40k lines, but for an actually large codebase, there are a bunch of different things that can help:

 - examine a class or function hierarchy and call graph. If you have tools to do so and the codebase is set up for it, go ahead. If not, set up the tools and codebase to be processed for this - you'll learn stuff about the code just by hooking these tools up.

 - pick medium-level routines in the code base that you are interested and run the applicaiton in the debugger with breakpoints set on them. Take a look at the callstacks, step through the callers, look at the arguments, etc.

 - you can also get a bunch of knowlege of the structure of the app by single stepping in the debugger - "step over" to see the high level control flow, and "step into" subsystems you want to explore.

 - documenting the existing code using a tool such as doxygen can help you learn it while at the same time providing useful documentation for other team members.</htmltext>
<tokenext>I would n't try too hard with a codebase as small as 30-40k lines , but for an actually large codebase , there are a bunch of different things that can help : - examine a class or function hierarchy and call graph .
If you have tools to do so and the codebase is set up for it , go ahead .
If not , set up the tools and codebase to be processed for this - you 'll learn stuff about the code just by hooking these tools up .
- pick medium-level routines in the code base that you are interested and run the applicaiton in the debugger with breakpoints set on them .
Take a look at the callstacks , step through the callers , look at the arguments , etc .
- you can also get a bunch of knowlege of the structure of the app by single stepping in the debugger - " step over " to see the high level control flow , and " step into " subsystems you want to explore .
- documenting the existing code using a tool such as doxygen can help you learn it while at the same time providing useful documentation for other team members .</tokentext>
<sentencetext>I wouldn't try too hard with a codebase as small as 30-40k lines, but for an actually large codebase, there are a bunch of different things that can help:

 - examine a class or function hierarchy and call graph.
If you have tools to do so and the codebase is set up for it, go ahead.
If not, set up the tools and codebase to be processed for this - you'll learn stuff about the code just by hooking these tools up.
- pick medium-level routines in the code base that you are interested and run the applicaiton in the debugger with breakpoints set on them.
Take a look at the callstacks, step through the callers, look at the arguments, etc.
- you can also get a bunch of knowlege of the structure of the app by single stepping in the debugger - "step over" to see the high level control flow, and "step into" subsystems you want to explore.
- documenting the existing code using a tool such as doxygen can help you learn it while at the same time providing useful documentation for other team members.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124708</id>
	<title>podcast on this issue</title>
	<author>Anonymous</author>
	<datestamp>1266000420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The Software Engineering Radio podcast at http://www.se-radio.net/ had a great show with Dave Thomas from the Pragmatic Programmers on this.</p></htmltext>
<tokenext>The Software Engineering Radio podcast at http : //www.se-radio.net/ had a great show with Dave Thomas from the Pragmatic Programmers on this .</tokentext>
<sentencetext>The Software Engineering Radio podcast at http://www.se-radio.net/ had a great show with Dave Thomas from the Pragmatic Programmers on this.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31151970</id>
	<title>30k to 40k is not big</title>
	<author>Anonymous</author>
	<datestamp>1266252960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I worked at Microsoft and several other large corporations.</p><p>Let me tell you: Anything less than 1 million lines of code is small.</p><p>You just need the right tools in order to handle large code bases.</p><p>First things to do:</p><p>1. Use source code version control (CVS, Svn, Git, Hg). Perform code reviews before check-in.<br>2. Use automatic compilation (make, ant, maven).<br>3. Use a build machine that pulls the source code from the Svn machine and builds it automatedly through ant or maven, sending email in case of failure, to detect compilation problems early.<br>4. Use an issue tracker to remember things to do and to keep track of time.<br>5. Use automatic unit tests (Junit and the like). Unit test every single method for all border cases. A test failure is a build failure and should be looked at immediatly.<br>6. Refactor mercilessly once everything has been unit tested. Avoid repeated code like the plague. Repeated code makes maintenance difficult, if not impossible.<br>7. Use AOP or proxies for logging and security.<br>8. Make sure no package has more than 10 classes, no class has more than 10 methods, no method has more than 10 lines. Refactor, refactor, refactor.<br>9. Make sure no class has more than 3 instance variables, no method has more than 3 parameters and no method has a loop AND a conditional sentence.<br>10. Make sure everything is specified only once (the DRY principle).</p></htmltext>
<tokenext>I worked at Microsoft and several other large corporations.Let me tell you : Anything less than 1 million lines of code is small.You just need the right tools in order to handle large code bases.First things to do : 1 .
Use source code version control ( CVS , Svn , Git , Hg ) .
Perform code reviews before check-in.2 .
Use automatic compilation ( make , ant , maven ) .3 .
Use a build machine that pulls the source code from the Svn machine and builds it automatedly through ant or maven , sending email in case of failure , to detect compilation problems early.4 .
Use an issue tracker to remember things to do and to keep track of time.5 .
Use automatic unit tests ( Junit and the like ) .
Unit test every single method for all border cases .
A test failure is a build failure and should be looked at immediatly.6 .
Refactor mercilessly once everything has been unit tested .
Avoid repeated code like the plague .
Repeated code makes maintenance difficult , if not impossible.7 .
Use AOP or proxies for logging and security.8 .
Make sure no package has more than 10 classes , no class has more than 10 methods , no method has more than 10 lines .
Refactor , refactor , refactor.9 .
Make sure no class has more than 3 instance variables , no method has more than 3 parameters and no method has a loop AND a conditional sentence.10 .
Make sure everything is specified only once ( the DRY principle ) .</tokentext>
<sentencetext>I worked at Microsoft and several other large corporations.Let me tell you: Anything less than 1 million lines of code is small.You just need the right tools in order to handle large code bases.First things to do:1.
Use source code version control (CVS, Svn, Git, Hg).
Perform code reviews before check-in.2.
Use automatic compilation (make, ant, maven).3.
Use a build machine that pulls the source code from the Svn machine and builds it automatedly through ant or maven, sending email in case of failure, to detect compilation problems early.4.
Use an issue tracker to remember things to do and to keep track of time.5.
Use automatic unit tests (Junit and the like).
Unit test every single method for all border cases.
A test failure is a build failure and should be looked at immediatly.6.
Refactor mercilessly once everything has been unit tested.
Avoid repeated code like the plague.
Repeated code makes maintenance difficult, if not impossible.7.
Use AOP or proxies for logging and security.8.
Make sure no package has more than 10 classes, no class has more than 10 methods, no method has more than 10 lines.
Refactor, refactor, refactor.9.
Make sure no class has more than 3 instance variables, no method has more than 3 parameters and no method has a loop AND a conditional sentence.10.
Make sure everything is specified only once (the DRY principle).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123136</id>
	<title>Design patterns are your friend</title>
	<author>PerlPunk</author>
	<datestamp>1265985240000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p> <i>"A couple of times in my career, I've inherited a fairly large (30-40 thousand lines) collection of code. The original authors knew it because they wrote it; I didn't, and I don't."</i> </p><p>A couple of times in your career? You must be lucky. Most jobs you can get coding will always involve taking over someone else's code.</p><p>In my experience, design patterns are your best friend, bearing in mind that most of the code base will always remain a black box to you.</p><p>For example, when I was doing some health insurance work, I had inherited a code base that was substantially larger than 30 or 40 thousand lines of code. The objective was to make the code that used an older, fixed-length record format work with the newer X837 EDI format, which is basically XML but almost without any tags to help you figure out where the data begins and ends.  Suffice it to say that the task was to figure out how to smoothly stick a square peg in a round hole.</p><p>The task itself determined the design patterns, of which an adapter pattern was the most used. The type of pattern in turn dictated what in the code to look for in order to implement it, and (of course) how the new code would be built. For example, since we were using an adapter pattern, the first order of business was to find out how the data was represented in the code base, and then trick the "black box" into using your own spiffy, new representation of the data.</p><p>For the most part I didn't have to care all that much how the application handled the data as long as I got the right data into a form the application would accept in my adapater.</p></htmltext>
<tokenext>" A couple of times in my career , I 've inherited a fairly large ( 30-40 thousand lines ) collection of code .
The original authors knew it because they wrote it ; I did n't , and I do n't .
" A couple of times in your career ?
You must be lucky .
Most jobs you can get coding will always involve taking over someone else 's code.In my experience , design patterns are your best friend , bearing in mind that most of the code base will always remain a black box to you.For example , when I was doing some health insurance work , I had inherited a code base that was substantially larger than 30 or 40 thousand lines of code .
The objective was to make the code that used an older , fixed-length record format work with the newer X837 EDI format , which is basically XML but almost without any tags to help you figure out where the data begins and ends .
Suffice it to say that the task was to figure out how to smoothly stick a square peg in a round hole.The task itself determined the design patterns , of which an adapter pattern was the most used .
The type of pattern in turn dictated what in the code to look for in order to implement it , and ( of course ) how the new code would be built .
For example , since we were using an adapter pattern , the first order of business was to find out how the data was represented in the code base , and then trick the " black box " into using your own spiffy , new representation of the data.For the most part I did n't have to care all that much how the application handled the data as long as I got the right data into a form the application would accept in my adapater .</tokentext>
<sentencetext> "A couple of times in my career, I've inherited a fairly large (30-40 thousand lines) collection of code.
The original authors knew it because they wrote it; I didn't, and I don't.
" A couple of times in your career?
You must be lucky.
Most jobs you can get coding will always involve taking over someone else's code.In my experience, design patterns are your best friend, bearing in mind that most of the code base will always remain a black box to you.For example, when I was doing some health insurance work, I had inherited a code base that was substantially larger than 30 or 40 thousand lines of code.
The objective was to make the code that used an older, fixed-length record format work with the newer X837 EDI format, which is basically XML but almost without any tags to help you figure out where the data begins and ends.
Suffice it to say that the task was to figure out how to smoothly stick a square peg in a round hole.The task itself determined the design patterns, of which an adapter pattern was the most used.
The type of pattern in turn dictated what in the code to look for in order to implement it, and (of course) how the new code would be built.
For example, since we were using an adapter pattern, the first order of business was to find out how the data was represented in the code base, and then trick the "black box" into using your own spiffy, new representation of the data.For the most part I didn't have to care all that much how the application handled the data as long as I got the right data into a form the application would accept in my adapater.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127336</id>
	<title>Re:Spaghetti Code</title>
	<author>ErikZ</author>
	<datestamp>1266079920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You also distilled 3 months of work into 4 paragraphs on Slashdot.</p></htmltext>
<tokenext>You also distilled 3 months of work into 4 paragraphs on Slashdot .</tokentext>
<sentencetext>You also distilled 3 months of work into 4 paragraphs on Slashdot.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123866</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123190</id>
	<title>Use it or lose it</title>
	<author>MpVpRb</author>
	<datestamp>1265985660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Somehow, I suspect that the original developers don't remember most of it either.

</p><p>Unless you work with it every day, little by little, you forget.

</p><p>First you forget the tricky parts.

</p><p>About the only thing you remember after a few years is the general structure.

</p><p>If you work with it every day, soon you will know it better than the original developers.</p></htmltext>
<tokenext>Somehow , I suspect that the original developers do n't remember most of it either .
Unless you work with it every day , little by little , you forget .
First you forget the tricky parts .
About the only thing you remember after a few years is the general structure .
If you work with it every day , soon you will know it better than the original developers .</tokentext>
<sentencetext>Somehow, I suspect that the original developers don't remember most of it either.
Unless you work with it every day, little by little, you forget.
First you forget the tricky parts.
About the only thing you remember after a few years is the general structure.
If you work with it every day, soon you will know it better than the original developers.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127506</id>
	<title>All you need is tags</title>
	<author>loufoque</author>
	<datestamp>1266080880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I just started a few months ago a job where I'm maintaining an old embedded system (an isdn gateway, old technology) that is supposedly written in C++, but is actually bad C.<br>It has no comments and no documentation of any kind. Indentation is broken beyond repair. A lot of functions are several thousand lines long, while most files are in tens of thousands of lines.</p><p>All I needed to deal with it was generate tags. Once you've got the tags, you can jump to a declaration or definition easily anywhere inside the code base. That, combined with grepping all the files of the project for the right strings or regular expressions (the system does a lot of logging, so I can just grep for the log message to find the relevant piece of code), makes the job doable.</p><p>But then, it's still a boring job with little opportunity to shine. I'm personally leaving whenever I can afford to move again.</p></htmltext>
<tokenext>I just started a few months ago a job where I 'm maintaining an old embedded system ( an isdn gateway , old technology ) that is supposedly written in C + + , but is actually bad C.It has no comments and no documentation of any kind .
Indentation is broken beyond repair .
A lot of functions are several thousand lines long , while most files are in tens of thousands of lines.All I needed to deal with it was generate tags .
Once you 've got the tags , you can jump to a declaration or definition easily anywhere inside the code base .
That , combined with grepping all the files of the project for the right strings or regular expressions ( the system does a lot of logging , so I can just grep for the log message to find the relevant piece of code ) , makes the job doable.But then , it 's still a boring job with little opportunity to shine .
I 'm personally leaving whenever I can afford to move again .</tokentext>
<sentencetext>I just started a few months ago a job where I'm maintaining an old embedded system (an isdn gateway, old technology) that is supposedly written in C++, but is actually bad C.It has no comments and no documentation of any kind.
Indentation is broken beyond repair.
A lot of functions are several thousand lines long, while most files are in tens of thousands of lines.All I needed to deal with it was generate tags.
Once you've got the tags, you can jump to a declaration or definition easily anywhere inside the code base.
That, combined with grepping all the files of the project for the right strings or regular expressions (the system does a lot of logging, so I can just grep for the log message to find the relevant piece of code), makes the job doable.But then, it's still a boring job with little opportunity to shine.
I'm personally leaving whenever I can afford to move again.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846</id>
	<title>That's small</title>
	<author>Anonymous</author>
	<datestamp>1265983320000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Medium size is 250 to 750 thousand lines of code (one person can still understand how it all works). Big is 1 to 10 million lines of code. Really big is &gt;10 million.</p><p>I have worked on code bases of all of those sizes, and I like the medium size the best -- it's big enough to be interesting, and small enough that you can understand it all.</p><p>One that I've worked on (over 25 million lines) is just too big for my tastes -- over 3 hours to do a clean recompile is excessive.</p></htmltext>
<tokenext>Medium size is 250 to 750 thousand lines of code ( one person can still understand how it all works ) .
Big is 1 to 10 million lines of code .
Really big is &gt; 10 million.I have worked on code bases of all of those sizes , and I like the medium size the best -- it 's big enough to be interesting , and small enough that you can understand it all.One that I 've worked on ( over 25 million lines ) is just too big for my tastes -- over 3 hours to do a clean recompile is excessive .</tokentext>
<sentencetext>Medium size is 250 to 750 thousand lines of code (one person can still understand how it all works).
Big is 1 to 10 million lines of code.
Really big is &gt;10 million.I have worked on code bases of all of those sizes, and I like the medium size the best -- it's big enough to be interesting, and small enough that you can understand it all.One that I've worked on (over 25 million lines) is just too big for my tastes -- over 3 hours to do a clean recompile is excessive.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128562</id>
	<title>Re:As a maintenance programmer</title>
	<author>Anonymous</author>
	<datestamp>1266088680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>This is great advice, but don't forget the basics.  In order to work effectively on code, you should know:<br>
&nbsp; &nbsp; What the code is supposed to be doing.<br>
&nbsp; &nbsp; What change in behavior you are trying to achieve.<br>
&nbsp; &nbsp; Where in the code to make the change.<br>
&nbsp; &nbsp; How to change to code for the desired affect.</p><p>
&nbsp; I find that finding the "where" almost always accounts for &gt;90\% of the job. Especially when you find relevant<br>variable names / code fragments in many places in the code.  So I would put my emphasis on concentrating<br>on the "where"  road map.</p><p>1.  First Background. What the code base is supposed to be doing, in both general terms and more specific.<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; What Domain elements, issues and problems are being addressed.<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; What Logical (Software Architectural) elements, processes, and steps achieve the desired Solution.<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; What VISIBLE program elements are used to achieve them.</p><p>2. As stated by many others: Where in the code is the main control loop,<br>
&nbsp; &nbsp; &nbsp; and where are the visible program elements called.</p><p>3.  What elements of the code base corresponds to each of the visible program elements.  What other elements<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; are only used by a particular element. (They are in the same logical box).</p><p>4.  What common utilities are used by many program elements and why.</p><p>This is the detailed road map that the creators of the code would know that allow them to quickly find<br>the right place in the code to make changes.  You can not work quickly without them.<br>Please, Record what you learn! You (or the next person down the road) will thank yourself later.</p><p>Ideally, you would spend enough upfront time getting oriented<br>to allow you to work effectively, but it never happens so...</p><p>The best sort of overall advice I can give you is:</p><p>
&nbsp; &nbsp; &nbsp; IF POSSIBLE, DON"T DO IT ALONE.</p><p>
&nbsp; Individuals who are expert: coders,  software architects, and domain specialists are rare, expensive, and<br>
&nbsp; probably don't have the  time or inclination to have a life outside the office (or read Slash-Dot).</p><p>Having two other specialists available: one Domain, and one Software Architecture, can drastically focus a Coders efforts.<br>Just having a buddy to throw ideas off can also be invaluable.<br>These resource would typically be used when first analyzing a task, and occasionally later, when new ideas are needed.</p><p>Also, don't forget to mine change-historys, they will provide hints of what modules do, what (and how often) they have been<br>changed and why.  I find it as a good way to find candidates for special attention.</p></htmltext>
<tokenext>This is great advice , but do n't forget the basics .
In order to work effectively on code , you should know :     What the code is supposed to be doing .
    What change in behavior you are trying to achieve .
    Where in the code to make the change .
    How to change to code for the desired affect .
  I find that finding the " where " almost always accounts for &gt; 90 \ % of the job .
Especially when you find relevantvariable names / code fragments in many places in the code .
So I would put my emphasis on concentratingon the " where " road map.1 .
First Background .
What the code base is supposed to be doing , in both general terms and more specific .
              What Domain elements , issues and problems are being addressed .
              What Logical ( Software Architectural ) elements , processes , and steps achieve the desired Solution .
              What VISIBLE program elements are used to achieve them.2 .
As stated by many others : Where in the code is the main control loop ,       and where are the visible program elements called.3 .
What elements of the code base corresponds to each of the visible program elements .
What other elements           are only used by a particular element .
( They are in the same logical box ) .4 .
What common utilities are used by many program elements and why.This is the detailed road map that the creators of the code would know that allow them to quickly findthe right place in the code to make changes .
You can not work quickly without them.Please , Record what you learn !
You ( or the next person down the road ) will thank yourself later.Ideally , you would spend enough upfront time getting orientedto allow you to work effectively , but it never happens so...The best sort of overall advice I can give you is :       IF POSSIBLE , DON " T DO IT ALONE .
  Individuals who are expert : coders , software architects , and domain specialists are rare , expensive , and   probably do n't have the time or inclination to have a life outside the office ( or read Slash-Dot ) .Having two other specialists available : one Domain , and one Software Architecture , can drastically focus a Coders efforts.Just having a buddy to throw ideas off can also be invaluable.These resource would typically be used when first analyzing a task , and occasionally later , when new ideas are needed.Also , do n't forget to mine change-historys , they will provide hints of what modules do , what ( and how often ) they have beenchanged and why .
I find it as a good way to find candidates for special attention .</tokentext>
<sentencetext>This is great advice, but don't forget the basics.
In order to work effectively on code, you should know:
    What the code is supposed to be doing.
    What change in behavior you are trying to achieve.
    Where in the code to make the change.
    How to change to code for the desired affect.
  I find that finding the "where" almost always accounts for &gt;90\% of the job.
Especially when you find relevantvariable names / code fragments in many places in the code.
So I would put my emphasis on concentratingon the "where"  road map.1.
First Background.
What the code base is supposed to be doing, in both general terms and more specific.
              What Domain elements, issues and problems are being addressed.
              What Logical (Software Architectural) elements, processes, and steps achieve the desired Solution.
              What VISIBLE program elements are used to achieve them.2.
As stated by many others: Where in the code is the main control loop,
      and where are the visible program elements called.3.
What elements of the code base corresponds to each of the visible program elements.
What other elements
          are only used by a particular element.
(They are in the same logical box).4.
What common utilities are used by many program elements and why.This is the detailed road map that the creators of the code would know that allow them to quickly findthe right place in the code to make changes.
You can not work quickly without them.Please, Record what you learn!
You (or the next person down the road) will thank yourself later.Ideally, you would spend enough upfront time getting orientedto allow you to work effectively, but it never happens so...The best sort of overall advice I can give you is:
      IF POSSIBLE, DON"T DO IT ALONE.
  Individuals who are expert: coders,  software architects, and domain specialists are rare, expensive, and
  probably don't have the  time or inclination to have a life outside the office (or read Slash-Dot).Having two other specialists available: one Domain, and one Software Architecture, can drastically focus a Coders efforts.Just having a buddy to throw ideas off can also be invaluable.These resource would typically be used when first analyzing a task, and occasionally later, when new ideas are needed.Also, don't forget to mine change-historys, they will provide hints of what modules do, what (and how often) they have beenchanged and why.
I find it as a good way to find candidates for special attention.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123054</id>
	<title>Re:It depends on the language</title>
	<author>LostCluster</author>
	<datestamp>1265984700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>VB6's actually very easy to understand when you have the code...</p><p>1. You can control-break at any point in program and be shown exactly the line you're executing and step through with F8 or resume at full speed with F5.<br>2. You've got a rather nice project-wide search tool to find functions and subs that the old programmer wrote.<br>3. You've got an immediate pane for simulating "What if X was set to..." situations.<br>4. The previous programmer likely left behind date-stamps in the OS so if a user can tell you when the feature was developed, you can see what files he was using.<br>5. There's a lot of stray VB how-to pages and books out there.</p></htmltext>
<tokenext>VB6 's actually very easy to understand when you have the code...1 .
You can control-break at any point in program and be shown exactly the line you 're executing and step through with F8 or resume at full speed with F5.2 .
You 've got a rather nice project-wide search tool to find functions and subs that the old programmer wrote.3 .
You 've got an immediate pane for simulating " What if X was set to... " situations.4 .
The previous programmer likely left behind date-stamps in the OS so if a user can tell you when the feature was developed , you can see what files he was using.5 .
There 's a lot of stray VB how-to pages and books out there .</tokentext>
<sentencetext>VB6's actually very easy to understand when you have the code...1.
You can control-break at any point in program and be shown exactly the line you're executing and step through with F8 or resume at full speed with F5.2.
You've got a rather nice project-wide search tool to find functions and subs that the old programmer wrote.3.
You've got an immediate pane for simulating "What if X was set to..." situations.4.
The previous programmer likely left behind date-stamps in the OS so if a user can tell you when the feature was developed, you can see what files he was using.5.
There's a lot of stray VB how-to pages and books out there.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122256</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124348</id>
	<title>Re:Use it</title>
	<author>bill\_mcgonigle</author>
	<datestamp>1265996100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>Am I off base here? What do you think about intermediate variables that are not strictly necessary?</i></p><p>Well, use your judgement.  Sometimes it helps.  Take two options:</p><p><tt><br>my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);<br>$mon++;       # 0-indexed from localtime<br>$year+= 1900; # years since 1900<br>print "At the tone the time will be: $year-$mon-$mday $hour:min:$sec\n";<br></tt></p><p>Or the more 'efficient':</p><p><tt><br>my @timeparts = localtime(time);<br>print 'At the tone the time will be: ' . $timeparts[5]+1900 . '-' . $timeparts[4]++ . "-$timeparts[3] $timeparts[2]:$timeparts[1]:$timeparts[0]\n";<br></tt></p><p>To the topic, which would you rather encounter as the next man on a codebase?  And don't forget that the compiler will optimize out any gratutious intermediates.</p></htmltext>
<tokenext>Am I off base here ?
What do you think about intermediate variables that are not strictly necessary ? Well , use your judgement .
Sometimes it helps .
Take two options : my ( $ sec , $ min , $ hour , $ mday , $ mon , $ year , $ wday , $ yday , $ isdst ) = localtime ( time ) ; $ mon + + ; # 0-indexed from localtime $ year + = 1900 ; # years since 1900print " At the tone the time will be : $ year- $ mon- $ mday $ hour : min : $ sec \ n " ; Or the more 'efficient ' : my @ timeparts = localtime ( time ) ; print 'At the tone the time will be : ' .
$ timeparts [ 5 ] + 1900 .
'- ' .
$ timeparts [ 4 ] + + .
" - $ timeparts [ 3 ] $ timeparts [ 2 ] : $ timeparts [ 1 ] : $ timeparts [ 0 ] \ n " ; To the topic , which would you rather encounter as the next man on a codebase ?
And do n't forget that the compiler will optimize out any gratutious intermediates .</tokentext>
<sentencetext>Am I off base here?
What do you think about intermediate variables that are not strictly necessary?Well, use your judgement.
Sometimes it helps.
Take two options:my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);$mon++;       # 0-indexed from localtime$year+= 1900; # years since 1900print "At the tone the time will be: $year-$mon-$mday $hour:min:$sec\n";Or the more 'efficient':my @timeparts = localtime(time);print 'At the tone the time will be: ' .
$timeparts[5]+1900 .
'-' .
$timeparts[4]++ .
"-$timeparts[3] $timeparts[2]:$timeparts[1]:$timeparts[0]\n";To the topic, which would you rather encounter as the next man on a codebase?
And don't forget that the compiler will optimize out any gratutious intermediates.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123646</id>
	<title>Software Archaeology</title>
	<author>tachyonflow</author>
	<datestamp>1265989380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>
I recently listened to an excellent Software Engineering Radio podcast on this very subject:
<a href="http://www.se-radio.net/podcast/2009-11/episode-148-software-archaeology-dave-thomas" title="se-radio.net">Episode 148: Software Archaeology with Dave Thomas</a> [se-radio.net]
</p><p>
This guy has a lot of good pointers.  (No pun intended.<nobr> <wbr></nobr>;)
</p></htmltext>
<tokenext>I recently listened to an excellent Software Engineering Radio podcast on this very subject : Episode 148 : Software Archaeology with Dave Thomas [ se-radio.net ] This guy has a lot of good pointers .
( No pun intended .
; )</tokentext>
<sentencetext>
I recently listened to an excellent Software Engineering Radio podcast on this very subject:
Episode 148: Software Archaeology with Dave Thomas [se-radio.net]

This guy has a lot of good pointers.
(No pun intended.
;)
</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126624</id>
	<title>Re:Not lots of code</title>
	<author>Anonymous</author>
	<datestamp>1266073500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I agree.  40 KLOC is laughable.</p></htmltext>
<tokenext>I agree .
40 KLOC is laughable .</tokentext>
<sentencetext>I agree.
40 KLOC is laughable.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31135852</id>
	<title>That depends...</title>
	<author>treczoks</author>
	<datestamp>1266176640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>One of my first inheritances at work was about 40k lines of code. One big ass file. Assembly, so I had no chance with Doxygen. Lots of macros to build totally different things depending on definitions and phase of the moon. Half of the comments were in french, which is erm, french to me. And each and every bit of RAM in the target was in use. "You only need to add this little feature." And be quick, because the system is already sold. And it is overdue, too, because someone in sales forgot to place a development job for the "small" change.
<br> <br>
And now tell me that 40k lines is small and easy...</htmltext>
<tokenext>One of my first inheritances at work was about 40k lines of code .
One big ass file .
Assembly , so I had no chance with Doxygen .
Lots of macros to build totally different things depending on definitions and phase of the moon .
Half of the comments were in french , which is erm , french to me .
And each and every bit of RAM in the target was in use .
" You only need to add this little feature .
" And be quick , because the system is already sold .
And it is overdue , too , because someone in sales forgot to place a development job for the " small " change .
And now tell me that 40k lines is small and easy.. .</tokentext>
<sentencetext>One of my first inheritances at work was about 40k lines of code.
One big ass file.
Assembly, so I had no chance with Doxygen.
Lots of macros to build totally different things depending on definitions and phase of the moon.
Half of the comments were in french, which is erm, french to me.
And each and every bit of RAM in the target was in use.
"You only need to add this little feature.
" And be quick, because the system is already sold.
And it is overdue, too, because someone in sales forgot to place a development job for the "small" change.
And now tell me that 40k lines is small and easy...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128392</id>
	<title>++i  can generate better code than i++</title>
	<author>Anonymous</author>
	<datestamp>1266087360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It's true.  You'd think the compiler could just do the same, but it can't, not always. i++ can have consequences. ++i never does.  But frankly, if you aren't doing billions of these a second...</p></htmltext>
<tokenext>It 's true .
You 'd think the compiler could just do the same , but it ca n't , not always .
i + + can have consequences .
+ + i never does .
But frankly , if you are n't doing billions of these a second.. .</tokentext>
<sentencetext>It's true.
You'd think the compiler could just do the same, but it can't, not always.
i++ can have consequences.
++i never does.
But frankly, if you aren't doing billions of these a second...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123616</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124558</id>
	<title>Source Browsing tools</title>
	<author>Anonymous</author>
	<datestamp>1265998620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>cscope or GNU Global are great for learning how code works. They are much more efficient than using find and grep.</p></htmltext>
<tokenext>cscope or GNU Global are great for learning how code works .
They are much more efficient than using find and grep .</tokentext>
<sentencetext>cscope or GNU Global are great for learning how code works.
They are much more efficient than using find and grep.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124174</id>
	<title>OpenGrok</title>
	<author>lytfyre</author>
	<datestamp>1265994360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>During a co-op job I worked on a very large multi-platform app (several million lines of code)
<br> <br>
the team had an <a href="http://lxr.linux.no/" title="linux.no" rel="nofollow">LXR</a> [linux.no] setup to do project wide searching, however it was aging and having problems, and is a bit difficult to work with.
<br>
As a side project intended for a report once I was back on campus, I set up <a href="http://hub.opensolaris.org/bin/view/Project+opengrok/" title="opensolaris.org" rel="nofollow">OpenGrok</a> [opensolaris.org], which worked brilliantly, and was reasonably easy to configure, and nicer to use once we got it setup. The team liked it enough that they switched to that permanently.
<br>
both are open source, and were built to handle large code bases (LXR was built for the linux kernel, OpenGrok for when Sun open sourced Solaris).
<br> <br>
Another one I had tried, which was very easy to setup was <a href="http://gonzui.sourceforge.net/" title="sourceforge.net" rel="nofollow">Gonzui.</a> [sourceforge.net] It's also open source, but didn't really handle the huge codebase as well as OpenGrok or LXR. For under 100k lines, it's probably fine, and the ease of setup may be worth it.
<br> <br>
All three provide a web interface, and do indexing as a separate process from search, so we would re-index the code base nightly.

works very well for larger teams, might be overkill for what you need though.</htmltext>
<tokenext>During a co-op job I worked on a very large multi-platform app ( several million lines of code ) the team had an LXR [ linux.no ] setup to do project wide searching , however it was aging and having problems , and is a bit difficult to work with .
As a side project intended for a report once I was back on campus , I set up OpenGrok [ opensolaris.org ] , which worked brilliantly , and was reasonably easy to configure , and nicer to use once we got it setup .
The team liked it enough that they switched to that permanently .
both are open source , and were built to handle large code bases ( LXR was built for the linux kernel , OpenGrok for when Sun open sourced Solaris ) .
Another one I had tried , which was very easy to setup was Gonzui .
[ sourceforge.net ] It 's also open source , but did n't really handle the huge codebase as well as OpenGrok or LXR .
For under 100k lines , it 's probably fine , and the ease of setup may be worth it .
All three provide a web interface , and do indexing as a separate process from search , so we would re-index the code base nightly .
works very well for larger teams , might be overkill for what you need though .</tokentext>
<sentencetext>During a co-op job I worked on a very large multi-platform app (several million lines of code)
 
the team had an LXR [linux.no] setup to do project wide searching, however it was aging and having problems, and is a bit difficult to work with.
As a side project intended for a report once I was back on campus, I set up OpenGrok [opensolaris.org], which worked brilliantly, and was reasonably easy to configure, and nicer to use once we got it setup.
The team liked it enough that they switched to that permanently.
both are open source, and were built to handle large code bases (LXR was built for the linux kernel, OpenGrok for when Sun open sourced Solaris).
Another one I had tried, which was very easy to setup was Gonzui.
[sourceforge.net] It's also open source, but didn't really handle the huge codebase as well as OpenGrok or LXR.
For under 100k lines, it's probably fine, and the ease of setup may be worth it.
All three provide a web interface, and do indexing as a separate process from search, so we would re-index the code base nightly.
works very well for larger teams, might be overkill for what you need though.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31133152</id>
	<title>Re:Not lots of code</title>
	<author>Chowderbags</author>
	<datestamp>1266138240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Yeah, and fuck those doctors who use laparoscopic robots to do surgery. What happens if they're at a restaurant and someone needs a tracheotomy right there and there's nothing but a semi-clean steak knife and some paper napkins?<br> <br>

Don't deride the use of a tool that solves quite a few problems just because it won't be there all the time. Is it good to know how to read a log or write good test harnesses? Absolutely. Does that mean I won't ever want to get a step-by-step feel for some sections of code? No.</htmltext>
<tokenext>Yeah , and fuck those doctors who use laparoscopic robots to do surgery .
What happens if they 're at a restaurant and someone needs a tracheotomy right there and there 's nothing but a semi-clean steak knife and some paper napkins ?
Do n't deride the use of a tool that solves quite a few problems just because it wo n't be there all the time .
Is it good to know how to read a log or write good test harnesses ?
Absolutely. Does that mean I wo n't ever want to get a step-by-step feel for some sections of code ?
No .</tokentext>
<sentencetext>Yeah, and fuck those doctors who use laparoscopic robots to do surgery.
What happens if they're at a restaurant and someone needs a tracheotomy right there and there's nothing but a semi-clean steak knife and some paper napkins?
Don't deride the use of a tool that solves quite a few problems just because it won't be there all the time.
Is it good to know how to read a log or write good test harnesses?
Absolutely. Does that mean I won't ever want to get a step-by-step feel for some sections of code?
No.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125540</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123462</id>
	<title>Don't get mad, get even.</title>
	<author>porky\_pig\_jr</author>
	<datestamp>1265987700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This is what I've done once upon a time.</p><p>1. Tell management the code is completely undocumented, not maintainable, unstructred piece of Dukakis.</p><p>2. Offer to rewrite the code completely. Chance are they would agree. Of course it depends how large is the code.</p><p>3. Rewrite the code. Make sure it's undocumented, not maintainable, unstructured piece of Dukakis.</p><p>4. Resign.</p></htmltext>
<tokenext>This is what I 've done once upon a time.1 .
Tell management the code is completely undocumented , not maintainable , unstructred piece of Dukakis.2 .
Offer to rewrite the code completely .
Chance are they would agree .
Of course it depends how large is the code.3 .
Rewrite the code .
Make sure it 's undocumented , not maintainable , unstructured piece of Dukakis.4 .
Resign .</tokentext>
<sentencetext>This is what I've done once upon a time.1.
Tell management the code is completely undocumented, not maintainable, unstructred piece of Dukakis.2.
Offer to rewrite the code completely.
Chance are they would agree.
Of course it depends how large is the code.3.
Rewrite the code.
Make sure it's undocumented, not maintainable, unstructured piece of Dukakis.4.
Resign.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125868</id>
	<title>Re:That's small</title>
	<author>Hurricane78</author>
	<datestamp>1266063300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Pff. <a href="http://www.haskell.org/haskellwiki/GHC" title="haskell.org">GHC</a> [haskell.org] takes over 8 hours and eats up to 8 GB of RAM (per compiled file) in the process.</p><p>I literally start compilation when I go to bed, and it&rsquo;s nearly finished when I wake up.</p></htmltext>
<tokenext>Pff .
GHC [ haskell.org ] takes over 8 hours and eats up to 8 GB of RAM ( per compiled file ) in the process.I literally start compilation when I go to bed , and it    s nearly finished when I wake up .</tokentext>
<sentencetext>Pff.
GHC [haskell.org] takes over 8 hours and eats up to 8 GB of RAM (per compiled file) in the process.I literally start compilation when I go to bed, and it’s nearly finished when I wake up.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31137286</id>
	<title>A few thoughts</title>
	<author>jgrahn</author>
	<datestamp>1266143640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>A few thoughts (in no particular order), without having read many of
the other comments.
<ul>
<li>Accept that it will be painful at first, and that you'll feel stupid a lot of the time.</li>
<li>The original developers probably didn't 'get' all of this code at
any one time, either. I'm the "original developer" in such a scenario right
now, and I cannot always answer detailed questions in any other way than
"I wrote it like that, saw that I could trust it, knew that I could
go back to it when needed, and then chose to forget the details".</li>
<li>Find a personal channel to the requirements and/or users. If you don't know what the code is supposed to do, you're fscked. And I don't mean what some paper says it should do, but what the *users* expects it to do. (I'm assuming there is a user base, and you're job is to push changes to them.)</li>
<li>Don't piss off those users. Be their friend, listen to them, understand their needs.
In return you can get things like better bug reports, better help testing new features, and
a big motivational factor.</li>
<li>Basic hygiene, if the original developers missed it:
turn on all compiler warnings, use tools like valgrind on the code.
Fix the build system if it sucks.</li>
<li>Learn tools to navigate the code *efficiently*, if you don't already.
For me they are
the Unix tools: emacs, find, grep, perl, nm and make. Probably others work
on other platforms and for other languages. I've never tried any new-fangled tools for that,
and doubt they work well, but your mileage may vary.</li>
<li>After working with the code for a while, you'll see patterns in it.
So that when you fix a certain feature, you'll see which subsystems probably aren't
involved and which ones can probably be trusted to do their job (even if they suck).</li>
</ul></htmltext>
<tokenext>A few thoughts ( in no particular order ) , without having read many of the other comments .
Accept that it will be painful at first , and that you 'll feel stupid a lot of the time .
The original developers probably did n't 'get ' all of this code at any one time , either .
I 'm the " original developer " in such a scenario right now , and I can not always answer detailed questions in any other way than " I wrote it like that , saw that I could trust it , knew that I could go back to it when needed , and then chose to forget the details " .
Find a personal channel to the requirements and/or users .
If you do n't know what the code is supposed to do , you 're fscked .
And I do n't mean what some paper says it should do , but what the * users * expects it to do .
( I 'm assuming there is a user base , and you 're job is to push changes to them .
) Do n't piss off those users .
Be their friend , listen to them , understand their needs .
In return you can get things like better bug reports , better help testing new features , and a big motivational factor .
Basic hygiene , if the original developers missed it : turn on all compiler warnings , use tools like valgrind on the code .
Fix the build system if it sucks .
Learn tools to navigate the code * efficiently * , if you do n't already .
For me they are the Unix tools : emacs , find , grep , perl , nm and make .
Probably others work on other platforms and for other languages .
I 've never tried any new-fangled tools for that , and doubt they work well , but your mileage may vary .
After working with the code for a while , you 'll see patterns in it .
So that when you fix a certain feature , you 'll see which subsystems probably are n't involved and which ones can probably be trusted to do their job ( even if they suck ) .</tokentext>
<sentencetext>A few thoughts (in no particular order), without having read many of
the other comments.
Accept that it will be painful at first, and that you'll feel stupid a lot of the time.
The original developers probably didn't 'get' all of this code at
any one time, either.
I'm the "original developer" in such a scenario right
now, and I cannot always answer detailed questions in any other way than
"I wrote it like that, saw that I could trust it, knew that I could
go back to it when needed, and then chose to forget the details".
Find a personal channel to the requirements and/or users.
If you don't know what the code is supposed to do, you're fscked.
And I don't mean what some paper says it should do, but what the *users* expects it to do.
(I'm assuming there is a user base, and you're job is to push changes to them.
)
Don't piss off those users.
Be their friend, listen to them, understand their needs.
In return you can get things like better bug reports, better help testing new features, and
a big motivational factor.
Basic hygiene, if the original developers missed it:
turn on all compiler warnings, use tools like valgrind on the code.
Fix the build system if it sucks.
Learn tools to navigate the code *efficiently*, if you don't already.
For me they are
the Unix tools: emacs, find, grep, perl, nm and make.
Probably others work
on other platforms and for other languages.
I've never tried any new-fangled tools for that,
and doubt they work well, but your mileage may vary.
After working with the code for a while, you'll see patterns in it.
So that when you fix a certain feature, you'll see which subsystems probably aren't
involved and which ones can probably be trusted to do their job (even if they suck).
</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31135114</id>
	<title>A decent IDE and/or Doxygen</title>
	<author>Anonymous</author>
	<datestamp>1266169620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If your particular language is supported an IDE can provide very easy navigation on the nagivation. You can branch through the code.</p><p>And doxygen can generate call trees and stuff which can help you.</p><p>Of course, the nature of your target language should support these (i.e. statically and strongly typed languages).</p></htmltext>
<tokenext>If your particular language is supported an IDE can provide very easy navigation on the nagivation .
You can branch through the code.And doxygen can generate call trees and stuff which can help you.Of course , the nature of your target language should support these ( i.e .
statically and strongly typed languages ) .</tokentext>
<sentencetext>If your particular language is supported an IDE can provide very easy navigation on the nagivation.
You can branch through the code.And doxygen can generate call trees and stuff which can help you.Of course, the nature of your target language should support these (i.e.
statically and strongly typed languages).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123756</id>
	<title>Only 30-40 thousand lines of code?</title>
	<author>Anonymous</author>
	<datestamp>1265990340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>That's nothing. Now if all of the files in the project are 30-40 thousand lines of copy-ghetti, well all I can say is good luck. May the refactoring be with you.</p></htmltext>
<tokenext>That 's nothing .
Now if all of the files in the project are 30-40 thousand lines of copy-ghetti , well all I can say is good luck .
May the refactoring be with you .</tokentext>
<sentencetext>That's nothing.
Now if all of the files in the project are 30-40 thousand lines of copy-ghetti, well all I can say is good luck.
May the refactoring be with you.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125482</id>
	<title>I'm doing this kind of work for the last 15 years</title>
	<author>Anonymous</author>
	<datestamp>1266056760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Many times my job is to help companies that had this kind of problem:</p><p>"We need to fix a bug/add a new feature to this huge code base"</p><p>Most of the time it's few hours max.</p><p>The "secret" of how I do it:</p><p>1. Don't say "Who's that as&amp;$## that wrote this code?" (it'll not help you)<br>2. Don't say "Why he code it that way? I could be done with much less code elsewhere" (it'll not help you either)<br>3. Your job is to find how  to add the requested change while not changing too much code. Always remember: Every line of code that you change = tons of new problems.<br>4. Tools needed: Notepad / vi / pico /  nano, Windows Explorer Search of XP / 'find' in unix, and the compiler is all I need. For this kind of jobs I'm not spending my time installing IDEs and doxygen.<br>5. Last thing to remember before starting to work: Try to avoid adding additional libraries that depending on other libraries / special system features. I'm trying to find open source / free and small code. Pure / close to pure ANSI C/C++ is the best. Few source files - best!<br>6. First step: Re-compile everything if it's not take too much time and run the compiled code to check if you have all the environment needed. If re-compile can take too much time (I had a project that taking over 24 hours to re-compile...) compile only the relevant modules.<br>7. First thing to do: try to break the code into modules but ignore any module not related to your task. Write a text file with all the relevant only things that you find.<br>8. Try to find the smallest change to do on the code. I can be a crazy change but the most important: it must be the smallest change.<br>9. Pray that it'll work<nobr> <wbr></nobr>:) "Good luck and may the force be with you"</p></htmltext>
<tokenext>Many times my job is to help companies that had this kind of problem : " We need to fix a bug/add a new feature to this huge code base " Most of the time it 's few hours max.The " secret " of how I do it : 1 .
Do n't say " Who 's that as&amp; $ # # that wrote this code ?
" ( it 'll not help you ) 2 .
Do n't say " Why he code it that way ?
I could be done with much less code elsewhere " ( it 'll not help you either ) 3 .
Your job is to find how to add the requested change while not changing too much code .
Always remember : Every line of code that you change = tons of new problems.4 .
Tools needed : Notepad / vi / pico / nano , Windows Explorer Search of XP / 'find ' in unix , and the compiler is all I need .
For this kind of jobs I 'm not spending my time installing IDEs and doxygen.5 .
Last thing to remember before starting to work : Try to avoid adding additional libraries that depending on other libraries / special system features .
I 'm trying to find open source / free and small code .
Pure / close to pure ANSI C/C + + is the best .
Few source files - best ! 6 .
First step : Re-compile everything if it 's not take too much time and run the compiled code to check if you have all the environment needed .
If re-compile can take too much time ( I had a project that taking over 24 hours to re-compile... ) compile only the relevant modules.7 .
First thing to do : try to break the code into modules but ignore any module not related to your task .
Write a text file with all the relevant only things that you find.8 .
Try to find the smallest change to do on the code .
I can be a crazy change but the most important : it must be the smallest change.9 .
Pray that it 'll work : ) " Good luck and may the force be with you "</tokentext>
<sentencetext>Many times my job is to help companies that had this kind of problem:"We need to fix a bug/add a new feature to this huge code base"Most of the time it's few hours max.The "secret" of how I do it:1.
Don't say "Who's that as&amp;$## that wrote this code?
" (it'll not help you)2.
Don't say "Why he code it that way?
I could be done with much less code elsewhere" (it'll not help you either)3.
Your job is to find how  to add the requested change while not changing too much code.
Always remember: Every line of code that you change = tons of new problems.4.
Tools needed: Notepad / vi / pico /  nano, Windows Explorer Search of XP / 'find' in unix, and the compiler is all I need.
For this kind of jobs I'm not spending my time installing IDEs and doxygen.5.
Last thing to remember before starting to work: Try to avoid adding additional libraries that depending on other libraries / special system features.
I'm trying to find open source / free and small code.
Pure / close to pure ANSI C/C++ is the best.
Few source files - best!6.
First step: Re-compile everything if it's not take too much time and run the compiled code to check if you have all the environment needed.
If re-compile can take too much time (I had a project that taking over 24 hours to re-compile...) compile only the relevant modules.7.
First thing to do: try to break the code into modules but ignore any module not related to your task.
Write a text file with all the relevant only things that you find.8.
Try to find the smallest change to do on the code.
I can be a crazy change but the most important: it must be the smallest change.9.
Pray that it'll work :) "Good luck and may the force be with you"</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124630</id>
	<title>But did the originals "get" it?</title>
	<author>MaxToTheMax</author>
	<datestamp>1265999460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I think the chances are very, very good that the original developers had the same problem you have.</htmltext>
<tokenext>I think the chances are very , very good that the original developers had the same problem you have .</tokentext>
<sentencetext>I think the chances are very, very good that the original developers had the same problem you have.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122440</id>
	<title>Large?</title>
	<author>Anonymous</author>
	<datestamp>1265981400000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Ha, ha!  Just 4 months ago I joined a project with a code base of about 500k lines.  I would call that (the 500k lines one) intermediate in size.  There are code bases with many millions of lines.  I now feel pretty comfortable finding things in it.  And I mostly use find and grep.</p></htmltext>
<tokenext>Ha , ha !
Just 4 months ago I joined a project with a code base of about 500k lines .
I would call that ( the 500k lines one ) intermediate in size .
There are code bases with many millions of lines .
I now feel pretty comfortable finding things in it .
And I mostly use find and grep .</tokentext>
<sentencetext>Ha, ha!
Just 4 months ago I joined a project with a code base of about 500k lines.
I would call that (the 500k lines one) intermediate in size.
There are code bases with many millions of lines.
I now feel pretty comfortable finding things in it.
And I mostly use find and grep.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122192</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124306</id>
	<title>ctags and cscope</title>
	<author>scotch</author>
	<datestamp>1265995680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>233 comments and not one mention of ctags or cscope yet.</htmltext>
<tokenext>233 comments and not one mention of ctags or cscope yet .</tokentext>
<sentencetext>233 comments and not one mention of ctags or cscope yet.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123866</id>
	<title>Spaghetti Code</title>
	<author>Hasai</author>
	<datestamp>1265991360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I was saddled with a ton of code at one point. It looked like it had been banged-out by the proverbial army of monkeys with typewriters, and they sure as hell didn't write Hamlet. It was pure spaghetti code, written by people who shouldn't have had access to an Etch-a-Sketch, let alone a computer.</p><p>I couldn't read it. It was COBOL for Pete's sake, and I couldn't read it. It just didn't make sense. I had to go find several DOZEN of those old IBM flowchart pads and a template, and chart-out every single instruction. Even then it didn't make any sense.</p><p>Finally, I took all the flowcharts and spread them out on the main computer room floor, a-la <i>A Beautiful Mind, </i>and go crawling around on them with a big fat red marker. My first break was when I realized roughly 60\% of the code was "dead:" it would never, ever be branched to. After striking-out all the dead code, I then wrestled with the file I/O, until I realized that whoever had written it had no concept of a buffer: the code would read a record, get a field, read the <i>same </i>record, get another field, etc.</p><p>In the end, I trashed roughly 78\% of the code and then re-wrote what was left. One program went from 64 pages to sixteen, then on the re-write went down to four. Yup; FOUR. Run-time for that same program went from sixteen HOURS to 32 MINUTES. Then I re-wrote it again, this time in 4GL, and the four pages became a half-page. THEN I had to go to the Big Boss and tell him that whoever had written the original code had rigged the program to generate falsified fiscal information. Yup; the thing lied right through its teeth. You should have seen the reaction.</p><p>Whole thing took about three months, untold amounts of coffee, and three bottles of Maalox. Have fun with your own code.</p></htmltext>
<tokenext>I was saddled with a ton of code at one point .
It looked like it had been banged-out by the proverbial army of monkeys with typewriters , and they sure as hell did n't write Hamlet .
It was pure spaghetti code , written by people who should n't have had access to an Etch-a-Sketch , let alone a computer.I could n't read it .
It was COBOL for Pete 's sake , and I could n't read it .
It just did n't make sense .
I had to go find several DOZEN of those old IBM flowchart pads and a template , and chart-out every single instruction .
Even then it did n't make any sense.Finally , I took all the flowcharts and spread them out on the main computer room floor , a-la A Beautiful Mind , and go crawling around on them with a big fat red marker .
My first break was when I realized roughly 60 \ % of the code was " dead : " it would never , ever be branched to .
After striking-out all the dead code , I then wrestled with the file I/O , until I realized that whoever had written it had no concept of a buffer : the code would read a record , get a field , read the same record , get another field , etc.In the end , I trashed roughly 78 \ % of the code and then re-wrote what was left .
One program went from 64 pages to sixteen , then on the re-write went down to four .
Yup ; FOUR .
Run-time for that same program went from sixteen HOURS to 32 MINUTES .
Then I re-wrote it again , this time in 4GL , and the four pages became a half-page .
THEN I had to go to the Big Boss and tell him that whoever had written the original code had rigged the program to generate falsified fiscal information .
Yup ; the thing lied right through its teeth .
You should have seen the reaction.Whole thing took about three months , untold amounts of coffee , and three bottles of Maalox .
Have fun with your own code .</tokentext>
<sentencetext>I was saddled with a ton of code at one point.
It looked like it had been banged-out by the proverbial army of monkeys with typewriters, and they sure as hell didn't write Hamlet.
It was pure spaghetti code, written by people who shouldn't have had access to an Etch-a-Sketch, let alone a computer.I couldn't read it.
It was COBOL for Pete's sake, and I couldn't read it.
It just didn't make sense.
I had to go find several DOZEN of those old IBM flowchart pads and a template, and chart-out every single instruction.
Even then it didn't make any sense.Finally, I took all the flowcharts and spread them out on the main computer room floor, a-la A Beautiful Mind, and go crawling around on them with a big fat red marker.
My first break was when I realized roughly 60\% of the code was "dead:" it would never, ever be branched to.
After striking-out all the dead code, I then wrestled with the file I/O, until I realized that whoever had written it had no concept of a buffer: the code would read a record, get a field, read the same record, get another field, etc.In the end, I trashed roughly 78\% of the code and then re-wrote what was left.
One program went from 64 pages to sixteen, then on the re-write went down to four.
Yup; FOUR.
Run-time for that same program went from sixteen HOURS to 32 MINUTES.
Then I re-wrote it again, this time in 4GL, and the four pages became a half-page.
THEN I had to go to the Big Boss and tell him that whoever had written the original code had rigged the program to generate falsified fiscal information.
Yup; the thing lied right through its teeth.
You should have seen the reaction.Whole thing took about three months, untold amounts of coffee, and three bottles of Maalox.
Have fun with your own code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124884</id>
	<title>What a trivial problem</title>
	<author>Anonymous</author>
	<datestamp>1266002520000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>30k-40k is not a lagre pile of code.</p><p>If your having problems either the code is poorly written and documented or you have risen to a job that is at the limit of your capacity.<br>I sugest refactoring the code a bit. It will tidy things up making you able to get to grips with it and let you have a tour of the code while your at it.</p><p>Under 500,000 lines of code should not provide any size issues for most good programmers. It is poorly maintained spagetti code that will fuck you up at even 5,000 lines.</p><p>If you get crappy code and you have to do any serious amount of work on it, your best path is to refactor.</p></htmltext>
<tokenext>30k-40k is not a lagre pile of code.If your having problems either the code is poorly written and documented or you have risen to a job that is at the limit of your capacity.I sugest refactoring the code a bit .
It will tidy things up making you able to get to grips with it and let you have a tour of the code while your at it.Under 500,000 lines of code should not provide any size issues for most good programmers .
It is poorly maintained spagetti code that will fuck you up at even 5,000 lines.If you get crappy code and you have to do any serious amount of work on it , your best path is to refactor .</tokentext>
<sentencetext>30k-40k is not a lagre pile of code.If your having problems either the code is poorly written and documented or you have risen to a job that is at the limit of your capacity.I sugest refactoring the code a bit.
It will tidy things up making you able to get to grips with it and let you have a tour of the code while your at it.Under 500,000 lines of code should not provide any size issues for most good programmers.
It is poorly maintained spagetti code that will fuck you up at even 5,000 lines.If you get crappy code and you have to do any serious amount of work on it, your best path is to refactor.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128006</id>
	<title>Re:As a maintenance programmer</title>
	<author>pommiekiwifruit</author>
	<datestamp>1266084780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Of course you will want to see if the bugs were producing output that people liked as well!
It is particularly nasty if a low-level pointer/bounds/uninitialized variable bug happens to (usually) hide a high-level design bug, and fixing it causes the design bug to be revealed...</htmltext>
<tokenext>Of course you will want to see if the bugs were producing output that people liked as well !
It is particularly nasty if a low-level pointer/bounds/uninitialized variable bug happens to ( usually ) hide a high-level design bug , and fixing it causes the design bug to be revealed.. .</tokentext>
<sentencetext>Of course you will want to see if the bugs were producing output that people liked as well!
It is particularly nasty if a low-level pointer/bounds/uninitialized variable bug happens to (usually) hide a high-level design bug, and fixing it causes the design bug to be revealed...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127800</id>
	<title>Re:Not lots of code</title>
	<author>Idarubicin</author>
	<datestamp>1266083100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>First of all, 30-40,000 lines of code is not lots of code. Try, 250,000 of code.</p></div><p>
A standard-sized novel runs about a hundred <i>thousand</i> words.  Weightier tomes, particularly those eight-hundred-pagers from the fantasy genre, can run to two or possibly even three times that.  If you figure that each sentence accomplishes one narrative 'task' and uses up about ten words, then a whole novel is about ten thousand lines of code.  (Some programming languages make this sort of correlation <a href="http://en.wikipedia.org/wiki/Shakespeare\_(programming\_language)" title="wikipedia.org">a bit more explicit</a> [wikipedia.org]).
</p><p>
It's silly to quibble over less than an order of magnitude when you're using vague terms like "lots".  And I'd argue that a novel's worth of code counts.</p></div>
	</htmltext>
<tokenext>First of all , 30-40,000 lines of code is not lots of code .
Try , 250,000 of code .
A standard-sized novel runs about a hundred thousand words .
Weightier tomes , particularly those eight-hundred-pagers from the fantasy genre , can run to two or possibly even three times that .
If you figure that each sentence accomplishes one narrative 'task ' and uses up about ten words , then a whole novel is about ten thousand lines of code .
( Some programming languages make this sort of correlation a bit more explicit [ wikipedia.org ] ) .
It 's silly to quibble over less than an order of magnitude when you 're using vague terms like " lots " .
And I 'd argue that a novel 's worth of code counts .</tokentext>
<sentencetext>First of all, 30-40,000 lines of code is not lots of code.
Try, 250,000 of code.
A standard-sized novel runs about a hundred thousand words.
Weightier tomes, particularly those eight-hundred-pagers from the fantasy genre, can run to two or possibly even three times that.
If you figure that each sentence accomplishes one narrative 'task' and uses up about ten words, then a whole novel is about ten thousand lines of code.
(Some programming languages make this sort of correlation a bit more explicit [wikipedia.org]).
It's silly to quibble over less than an order of magnitude when you're using vague terms like "lots".
And I'd argue that a novel's worth of code counts.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125802</id>
	<title>Re:Not lots of code</title>
	<author>Hurricane78</author>
	<datestamp>1266062280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Try, 250,000 of code.</p></div><p>Which would be about 2,500 lines of Haskell code.<br>And 247,500 lines of documentation to make sense of them.<nobr> <wbr></nobr>;)</p></div>
	</htmltext>
<tokenext>Try , 250,000 of code.Which would be about 2,500 lines of Haskell code.And 247,500 lines of documentation to make sense of them .
; )</tokentext>
<sentencetext>Try, 250,000 of code.Which would be about 2,500 lines of Haskell code.And 247,500 lines of documentation to make sense of them.
;)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123940</id>
	<title>One bug fix at a time</title>
	<author>codgur</author>
	<datestamp>1265992020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Once for over 1 year my sole job was to maintain the most lucrative product for the company (millions/year).  There were numerous other products with newer technology but this was a legacy system comprised of a C++ socket based service and numerous front end scripts and middle tier C++ components (~15-20k lines of code in all those aforementioned technologies).  Any wrong change could cost thousands of dollars / day if not more.  There were bug fix projects and enhancement projects.  I learned that you learn the code one-bug-fix-at-a-time.  The first goal is to get it working.  Second goal is to break it on purpose and generally play around with the system. Also become very intimate with a debugger.  It will make or break you.

I didn't have the luxury of having the 'original developers' around (they were fired) so there was no prior knowledge. You are looking to keep your job for a while aren't you?  Those who can do maintenance work (everyone wants to work on the new and latest code and coolest projects) will be employable till time ends. It is not glory work. Having done it for over 1 year on the same project I can tell you that the maintenance coder is not in it for the glory but rather for the satisfaction of a job well done AND for a steady paycheck.</htmltext>
<tokenext>Once for over 1 year my sole job was to maintain the most lucrative product for the company ( millions/year ) .
There were numerous other products with newer technology but this was a legacy system comprised of a C + + socket based service and numerous front end scripts and middle tier C + + components ( ~ 15-20k lines of code in all those aforementioned technologies ) .
Any wrong change could cost thousands of dollars / day if not more .
There were bug fix projects and enhancement projects .
I learned that you learn the code one-bug-fix-at-a-time .
The first goal is to get it working .
Second goal is to break it on purpose and generally play around with the system .
Also become very intimate with a debugger .
It will make or break you .
I did n't have the luxury of having the 'original developers ' around ( they were fired ) so there was no prior knowledge .
You are looking to keep your job for a while are n't you ?
Those who can do maintenance work ( everyone wants to work on the new and latest code and coolest projects ) will be employable till time ends .
It is not glory work .
Having done it for over 1 year on the same project I can tell you that the maintenance coder is not in it for the glory but rather for the satisfaction of a job well done AND for a steady paycheck .</tokentext>
<sentencetext>Once for over 1 year my sole job was to maintain the most lucrative product for the company (millions/year).
There were numerous other products with newer technology but this was a legacy system comprised of a C++ socket based service and numerous front end scripts and middle tier C++ components (~15-20k lines of code in all those aforementioned technologies).
Any wrong change could cost thousands of dollars / day if not more.
There were bug fix projects and enhancement projects.
I learned that you learn the code one-bug-fix-at-a-time.
The first goal is to get it working.
Second goal is to break it on purpose and generally play around with the system.
Also become very intimate with a debugger.
It will make or break you.
I didn't have the luxury of having the 'original developers' around (they were fired) so there was no prior knowledge.
You are looking to keep your job for a while aren't you?
Those who can do maintenance work (everyone wants to work on the new and latest code and coolest projects) will be employable till time ends.
It is not glory work.
Having done it for over 1 year on the same project I can tell you that the maintenance coder is not in it for the glory but rather for the satisfaction of a job well done AND for a steady paycheck.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123434</id>
	<title>Re:Use it</title>
	<author>Anonymous</author>
	<datestamp>1265987460000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>The main thing that bothers me when working with other peoples code is the sheer number of variables they use. I tend not to declare a new variable unless it is absolutely necessary (and in object oriented programming variables other than pointers are almost never necessary). It seems like code written this way is easier to read and understand (and significantly smaller). This is slashdot, so there are a lot of other programmers out there. Am I off base here</i></p><p>No, you're on target.  Making a variable to temporarily store a variable amounts to writing unnecessary plumbing.  You can abstract that plumbing out very easily, through "functional monadism".  This makes things much easier:  you can manipulate the plumbing apart from the things it plumbs.</p><p>You are definitely on the right track.  If you haven't done this, try learning SQL, and then a functional programming language.  You will see that the computation of a function amounts to the computation of a subset of the cartesian product of types (or sets, more generally).  Evaluating a function amounts to evaluating a query.  It's easiest to write queries against data types in certain "normal forms".  This means that a program has three essential components:  definitions of the normal forms (the data definition languages for SQL), queries to run against values of these forms, and, as a practical matter, data to query.</p></htmltext>
<tokenext>The main thing that bothers me when working with other peoples code is the sheer number of variables they use .
I tend not to declare a new variable unless it is absolutely necessary ( and in object oriented programming variables other than pointers are almost never necessary ) .
It seems like code written this way is easier to read and understand ( and significantly smaller ) .
This is slashdot , so there are a lot of other programmers out there .
Am I off base hereNo , you 're on target .
Making a variable to temporarily store a variable amounts to writing unnecessary plumbing .
You can abstract that plumbing out very easily , through " functional monadism " .
This makes things much easier : you can manipulate the plumbing apart from the things it plumbs.You are definitely on the right track .
If you have n't done this , try learning SQL , and then a functional programming language .
You will see that the computation of a function amounts to the computation of a subset of the cartesian product of types ( or sets , more generally ) .
Evaluating a function amounts to evaluating a query .
It 's easiest to write queries against data types in certain " normal forms " .
This means that a program has three essential components : definitions of the normal forms ( the data definition languages for SQL ) , queries to run against values of these forms , and , as a practical matter , data to query .</tokentext>
<sentencetext>The main thing that bothers me when working with other peoples code is the sheer number of variables they use.
I tend not to declare a new variable unless it is absolutely necessary (and in object oriented programming variables other than pointers are almost never necessary).
It seems like code written this way is easier to read and understand (and significantly smaller).
This is slashdot, so there are a lot of other programmers out there.
Am I off base hereNo, you're on target.
Making a variable to temporarily store a variable amounts to writing unnecessary plumbing.
You can abstract that plumbing out very easily, through "functional monadism".
This makes things much easier:  you can manipulate the plumbing apart from the things it plumbs.You are definitely on the right track.
If you haven't done this, try learning SQL, and then a functional programming language.
You will see that the computation of a function amounts to the computation of a subset of the cartesian product of types (or sets, more generally).
Evaluating a function amounts to evaluating a query.
It's easiest to write queries against data types in certain "normal forms".
This means that a program has three essential components:  definitions of the normal forms (the data definition languages for SQL), queries to run against values of these forms, and, as a practical matter, data to query.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125580</id>
	<title>Re:My Dick is Bigger than Your 250,000 lines of co</title>
	<author>greg1104</author>
	<datestamp>1266058740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>it is a sizeable task, and is the type of topic that few professional journals or books will ever be written about.</p></div><p>Right, no one has ever <a href="http://www.amazon.com/Software-Exorcism-Handbook-Debugging-Optimizing/dp/1590592344/" title="amazon.com">written a single</a> [amazon.com] <a href="http://www.amazon.com/Software-Exorcism-Handbook-Debugging-Optimizing/dp/1590592344/" title="amazon.com">book on that topic</a> [amazon.com].</p></div>
	</htmltext>
<tokenext>it is a sizeable task , and is the type of topic that few professional journals or books will ever be written about.Right , no one has ever written a single [ amazon.com ] book on that topic [ amazon.com ] .</tokentext>
<sentencetext>it is a sizeable task, and is the type of topic that few professional journals or books will ever be written about.Right, no one has ever written a single [amazon.com] book on that topic [amazon.com].
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123466</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123420</id>
	<title>Re:That's small</title>
	<author>Anonymous</author>
	<datestamp>1265987280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>30-40K is a large codebase?  Kids these days.</p></htmltext>
<tokenext>30-40K is a large codebase ?
Kids these days .</tokentext>
<sentencetext>30-40K is a large codebase?
Kids these days.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127646</id>
	<title>Re:Use it</title>
	<author>ciggieposeur</author>
	<datestamp>1266081900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>Use one or the other consistently? But they don't mean the same thing.</i></p><p>They compile to the same thing if they are both used with the meaning "increment this thing by one".  If they are used to mean "increment-then-evaluate" or "evaluate-then-increment", one may as well separate the increment from the evaluate because the combination only (maybe) makes it easier for the lexer/parser, not the next human assigned to maintain the code X years later.</p><p>I'm fine with "i += 1" or even "i = i + 1".  If I want to increment, I increment; if I want to evaluate, I evaluate.</p></htmltext>
<tokenext>Use one or the other consistently ?
But they do n't mean the same thing.They compile to the same thing if they are both used with the meaning " increment this thing by one " .
If they are used to mean " increment-then-evaluate " or " evaluate-then-increment " , one may as well separate the increment from the evaluate because the combination only ( maybe ) makes it easier for the lexer/parser , not the next human assigned to maintain the code X years later.I 'm fine with " i + = 1 " or even " i = i + 1 " .
If I want to increment , I increment ; if I want to evaluate , I evaluate .</tokentext>
<sentencetext>Use one or the other consistently?
But they don't mean the same thing.They compile to the same thing if they are both used with the meaning "increment this thing by one".
If they are used to mean "increment-then-evaluate" or "evaluate-then-increment", one may as well separate the increment from the evaluate because the combination only (maybe) makes it easier for the lexer/parser, not the next human assigned to maintain the code X years later.I'm fine with "i += 1" or even "i = i + 1".
If I want to increment, I increment; if I want to evaluate, I evaluate.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124248</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125698</id>
	<title>Re:40,000?!? ARE YOU KIDDING ME?</title>
	<author>heson</author>
	<datestamp>1266060420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Ooooh yeah. <br>
Four #includes and a line that starts "int main" is all you need.</htmltext>
<tokenext>Ooooh yeah .
Four # includes and a line that starts " int main " is all you need .</tokentext>
<sentencetext>Ooooh yeah.
Four #includes and a line that starts "int main" is all you need.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123068</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31139942</id>
	<title>Spaghetti Code!</title>
	<author>Anonymous</author>
	<datestamp>1266161940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>http://sourcemaking.com/antipatterns/spaghetti-code</p></htmltext>
<tokenext>http : //sourcemaking.com/antipatterns/spaghetti-code</tokentext>
<sentencetext>http://sourcemaking.com/antipatterns/spaghetti-code</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124370</id>
	<title>Re:As a maintenance programmer</title>
	<author>bill\_mcgonigle</author>
	<datestamp>1265996400000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p><i>truly learn the software.</i></p><p>And then if your unit tests work you'll know enough to comment the code correctly for the next time you or your successor comes back to it.</p></htmltext>
<tokenext>truly learn the software.And then if your unit tests work you 'll know enough to comment the code correctly for the next time you or your successor comes back to it .</tokentext>
<sentencetext>truly learn the software.And then if your unit tests work you'll know enough to comment the code correctly for the next time you or your successor comes back to it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123032</id>
	<title>I found this tool excellent for code comprehension</title>
	<author>Wainamoinen</author>
	<datestamp>1265984580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Check it out, it's called <a href="http://tibleiz.net/code-browser/" title="tibleiz.net" rel="nofollow">Code Browser</a> [tibleiz.net] . It's a lightweight and powerful editor that allows you to visualize, structurate, link, organize, comment and edit code.</p><p>It's my favorite one for very large projects with houdreds of files and thousands of lines.</p><p>From the project's description:</p><p>"Code Browser is a folding text editor for Linux and Windows, designed to hierarchically structure any kind of text file and especially source code. It makes navigation through source code faster and easier."<br>"Code Browser is especially designed to keep a good overview of the code of large projects, but is also useful for a simple css file. Ideal if you are fed up of having to scroll through thousands of lines of code. "</p><p>Have fun!</p></htmltext>
<tokenext>Check it out , it 's called Code Browser [ tibleiz.net ] .
It 's a lightweight and powerful editor that allows you to visualize , structurate , link , organize , comment and edit code.It 's my favorite one for very large projects with houdreds of files and thousands of lines.From the project 's description : " Code Browser is a folding text editor for Linux and Windows , designed to hierarchically structure any kind of text file and especially source code .
It makes navigation through source code faster and easier .
" " Code Browser is especially designed to keep a good overview of the code of large projects , but is also useful for a simple css file .
Ideal if you are fed up of having to scroll through thousands of lines of code .
" Have fun !</tokentext>
<sentencetext>Check it out, it's called Code Browser [tibleiz.net] .
It's a lightweight and powerful editor that allows you to visualize, structurate, link, organize, comment and edit code.It's my favorite one for very large projects with houdreds of files and thousands of lines.From the project's description:"Code Browser is a folding text editor for Linux and Windows, designed to hierarchically structure any kind of text file and especially source code.
It makes navigation through source code faster and easier.
""Code Browser is especially designed to keep a good overview of the code of large projects, but is also useful for a simple css file.
Ideal if you are fed up of having to scroll through thousands of lines of code.
"Have fun!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122290</id>
	<title>Visualisation</title>
	<author>Anonymous</author>
	<datestamp>1265980620000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>Anything ranging from just sketching out some informal package diagrams on some paper (I quite like using an A3 sketchpad) to something more like <a href="http://www.inf.usi.ch/phd/wettel/index.html" title="inf.usi.ch">Code City</a> [inf.usi.ch] which can work with code in smalltalk, java, and c++. There are UML diagram makers, of course, but automated diagrams like that probably need to be edited.</p><p>In fact, it is not the finished diagram that helps so much as the drawing of it, which is why paper and pencil is so good. Or a vector graphics package.</p></htmltext>
<tokenext>Anything ranging from just sketching out some informal package diagrams on some paper ( I quite like using an A3 sketchpad ) to something more like Code City [ inf.usi.ch ] which can work with code in smalltalk , java , and c + + .
There are UML diagram makers , of course , but automated diagrams like that probably need to be edited.In fact , it is not the finished diagram that helps so much as the drawing of it , which is why paper and pencil is so good .
Or a vector graphics package .</tokentext>
<sentencetext>Anything ranging from just sketching out some informal package diagrams on some paper (I quite like using an A3 sketchpad) to something more like Code City [inf.usi.ch] which can work with code in smalltalk, java, and c++.
There are UML diagram makers, of course, but automated diagrams like that probably need to be edited.In fact, it is not the finished diagram that helps so much as the drawing of it, which is why paper and pencil is so good.
Or a vector graphics package.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123468</id>
	<title>Re:It depends on the language</title>
	<author>BerntB</author>
	<datestamp>1265987760000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Funny you should say that.,,</p><p>
I quite like this reference from the Perl world about understanding large systems: <a href="http://www.perlmonks.org/?node\_id=788328" title="perlmonks.org">http://www.perlmonks.org/?node\_id=788328</a> [perlmonks.org]
</p></htmltext>
<tokenext>Funny you should say that., , I quite like this reference from the Perl world about understanding large systems : http : //www.perlmonks.org/ ? node \ _id = 788328 [ perlmonks.org ]</tokentext>
<sentencetext>Funny you should say that.,,
I quite like this reference from the Perl world about understanding large systems: http://www.perlmonks.org/?node\_id=788328 [perlmonks.org]
</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122256</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122502</id>
	<title>*gasp*</title>
	<author>Anonymous</author>
	<datestamp>1265981640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You mean they didn't comment all their code? *gasp*</p></htmltext>
<tokenext>You mean they did n't comment all their code ?
* gasp *</tokentext>
<sentencetext>You mean they didn't comment all their code?
*gasp*</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123314</id>
	<title>Re:Not lots of code</title>
	<author>npsimons</author>
	<datestamp>1265986500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>To start, use a good programming editor/environment (Xcode, Vslick, Visual Studio, etc.) that gives you the ability to easily go to definition or references to variables, functions, structs and such.</p></div></blockquote><p>I have to put in a word for Emacs, which Works For Me, and Works Very Well, ThankYouVeryMuch.  Never did like XCode, Vslick, VisualStudio, Eclipse or any of those others.  Of course, if the poster isn't using Emacs already, that's just another learning curve they will have to climb, I admit.  What it boils down to: does your favorite editor support looking up definitions of names in code?  If not, switch to one that does, preferably one that is similar to your favorite editor.  If you are using Emacs and hitting up against the limits of etags, take a look at <a href="http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html" title="alexott.net">CEDET</a> [alexott.net], in case you haven't already.</p><blockquote><div><p>Run some sort of profiler or flowchart type program on it to get a high level view of the code and how it fits together.</p></div></blockquote><p>Huh.  Much as I harp on using profiler's, I would argue that they aren't very helpful at this stage in the game.  Granted, most of the code I get to maintain is a mess that won't help by being profiled.  However, any tool you can get that helps pick apart the code automatically is a Good Thing; I second this.</p></div>
	</htmltext>
<tokenext>To start , use a good programming editor/environment ( Xcode , Vslick , Visual Studio , etc .
) that gives you the ability to easily go to definition or references to variables , functions , structs and such.I have to put in a word for Emacs , which Works For Me , and Works Very Well , ThankYouVeryMuch .
Never did like XCode , Vslick , VisualStudio , Eclipse or any of those others .
Of course , if the poster is n't using Emacs already , that 's just another learning curve they will have to climb , I admit .
What it boils down to : does your favorite editor support looking up definitions of names in code ?
If not , switch to one that does , preferably one that is similar to your favorite editor .
If you are using Emacs and hitting up against the limits of etags , take a look at CEDET [ alexott.net ] , in case you have n't already.Run some sort of profiler or flowchart type program on it to get a high level view of the code and how it fits together.Huh .
Much as I harp on using profiler 's , I would argue that they are n't very helpful at this stage in the game .
Granted , most of the code I get to maintain is a mess that wo n't help by being profiled .
However , any tool you can get that helps pick apart the code automatically is a Good Thing ; I second this .</tokentext>
<sentencetext>To start, use a good programming editor/environment (Xcode, Vslick, Visual Studio, etc.
) that gives you the ability to easily go to definition or references to variables, functions, structs and such.I have to put in a word for Emacs, which Works For Me, and Works Very Well, ThankYouVeryMuch.
Never did like XCode, Vslick, VisualStudio, Eclipse or any of those others.
Of course, if the poster isn't using Emacs already, that's just another learning curve they will have to climb, I admit.
What it boils down to: does your favorite editor support looking up definitions of names in code?
If not, switch to one that does, preferably one that is similar to your favorite editor.
If you are using Emacs and hitting up against the limits of etags, take a look at CEDET [alexott.net], in case you haven't already.Run some sort of profiler or flowchart type program on it to get a high level view of the code and how it fits together.Huh.
Much as I harp on using profiler's, I would argue that they aren't very helpful at this stage in the game.
Granted, most of the code I get to maintain is a mess that won't help by being profiled.
However, any tool you can get that helps pick apart the code automatically is a Good Thing; I second this.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31137334</id>
	<title>some steps I'd take</title>
	<author>multicsfan</author>
	<datestamp>1266143940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>There are many things I'd do and some are dependent on the language as some things make more sense in some languages and less in others.</p><p>First thing I'd do is get all the existing documentation I can find including the end user documentation of how to use the software.</p><p>I'd next try to break the software down by modules, subroutines, functions, library routines, etc. to get an idea of what does what.  I'd also try to determine variable usage, such as local vs global variables and where things are defined.</p><p>If the above is not already documented I'd work on creating the documentation so I don't have to refigure things out each time I dig into the code for something.</p><p>The code style of the previous people who worked with the code can be very important.  Some languages are easier to write obscured code in then others.  If the code is NOT documented or the documentation is obsolete I'd start working on the inline documentation.  Anyplace that the code is very obscured or poorly written I might look into rewriting so the code is easier to document and easier to read.</p><p>Don't trust any of the documentation until you've made sure it is up to date.</p><p>At one of my jobs the package I was hired to maintain, support, and enhance had been modified on a per customer basis where some varialbes had different meanings in different versions.  There where some features where the feature was implimented differently in different systems to meet different customers differing and conflicting needs.  In some cases the mainline module code would look the same but the differences would be hidden in the subroutines.  This was made even more complicated by being a multiuser application that did its own file locking.  The original application had been single user so there was more then one method of gdoing file locking, some of which was based on what files where in which 'partition'.  The system only allowed locking entire 'partitions' at one time.  As customer grew to need multiple disks with multiple partitions the multiuser locking would erratically fail, corrupt data or deadlock, etc.</p><p>Look for the tools people mentioned that can help you easier figure out how things work.  There were no tools for the system I worked on so I had to create my own (proprietary non-standed OS and interpreted language)..  My boss complained aobut some of the time I spent working on the tools until he saw how they were saving time and helping make it easier to make changes.</p><p>Don't be afraid to look for tools to make your life easier.  Don't be afraid to write your own if there is a good reason to do so.</p><p>The system I worked with was about 200 programs / customer with about 200 subroutines (sometimes unique for a customer) in each system.</p></htmltext>
<tokenext>There are many things I 'd do and some are dependent on the language as some things make more sense in some languages and less in others.First thing I 'd do is get all the existing documentation I can find including the end user documentation of how to use the software.I 'd next try to break the software down by modules , subroutines , functions , library routines , etc .
to get an idea of what does what .
I 'd also try to determine variable usage , such as local vs global variables and where things are defined.If the above is not already documented I 'd work on creating the documentation so I do n't have to refigure things out each time I dig into the code for something.The code style of the previous people who worked with the code can be very important .
Some languages are easier to write obscured code in then others .
If the code is NOT documented or the documentation is obsolete I 'd start working on the inline documentation .
Anyplace that the code is very obscured or poorly written I might look into rewriting so the code is easier to document and easier to read.Do n't trust any of the documentation until you 've made sure it is up to date.At one of my jobs the package I was hired to maintain , support , and enhance had been modified on a per customer basis where some varialbes had different meanings in different versions .
There where some features where the feature was implimented differently in different systems to meet different customers differing and conflicting needs .
In some cases the mainline module code would look the same but the differences would be hidden in the subroutines .
This was made even more complicated by being a multiuser application that did its own file locking .
The original application had been single user so there was more then one method of gdoing file locking , some of which was based on what files where in which 'partition' .
The system only allowed locking entire 'partitions ' at one time .
As customer grew to need multiple disks with multiple partitions the multiuser locking would erratically fail , corrupt data or deadlock , etc.Look for the tools people mentioned that can help you easier figure out how things work .
There were no tools for the system I worked on so I had to create my own ( proprietary non-standed OS and interpreted language ) .. My boss complained aobut some of the time I spent working on the tools until he saw how they were saving time and helping make it easier to make changes.Do n't be afraid to look for tools to make your life easier .
Do n't be afraid to write your own if there is a good reason to do so.The system I worked with was about 200 programs / customer with about 200 subroutines ( sometimes unique for a customer ) in each system .</tokentext>
<sentencetext>There are many things I'd do and some are dependent on the language as some things make more sense in some languages and less in others.First thing I'd do is get all the existing documentation I can find including the end user documentation of how to use the software.I'd next try to break the software down by modules, subroutines, functions, library routines, etc.
to get an idea of what does what.
I'd also try to determine variable usage, such as local vs global variables and where things are defined.If the above is not already documented I'd work on creating the documentation so I don't have to refigure things out each time I dig into the code for something.The code style of the previous people who worked with the code can be very important.
Some languages are easier to write obscured code in then others.
If the code is NOT documented or the documentation is obsolete I'd start working on the inline documentation.
Anyplace that the code is very obscured or poorly written I might look into rewriting so the code is easier to document and easier to read.Don't trust any of the documentation until you've made sure it is up to date.At one of my jobs the package I was hired to maintain, support, and enhance had been modified on a per customer basis where some varialbes had different meanings in different versions.
There where some features where the feature was implimented differently in different systems to meet different customers differing and conflicting needs.
In some cases the mainline module code would look the same but the differences would be hidden in the subroutines.
This was made even more complicated by being a multiuser application that did its own file locking.
The original application had been single user so there was more then one method of gdoing file locking, some of which was based on what files where in which 'partition'.
The system only allowed locking entire 'partitions' at one time.
As customer grew to need multiple disks with multiple partitions the multiuser locking would erratically fail, corrupt data or deadlock, etc.Look for the tools people mentioned that can help you easier figure out how things work.
There were no tools for the system I worked on so I had to create my own (proprietary non-standed OS and interpreted language)..  My boss complained aobut some of the time I spent working on the tools until he saw how they were saving time and helping make it easier to make changes.Don't be afraid to look for tools to make your life easier.
Don't be afraid to write your own if there is a good reason to do so.The system I worked with was about 200 programs / customer with about 200 subroutines (sometimes unique for a customer) in each system.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31129116</id>
	<title>Cybertao</title>
	<author>tgrigsby</author>
	<datestamp>1266093120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Okay, first off, 40k lines isn't big, and unless they did a really horrible job of naming and organizing the parts, it shouldn't be hard to tackle.  I'm dealing with a 1.5 million line assortment of legacy code, and while it's taken a while to suss out, I have a pretty decent grasp of where everything is.</p><p>It's a Zen thing.  You look it over until you identify the top level units, then work your way down.  Most applications have a framework.  If you can't find a starting point, figure out which code is the most outward facing, read through the high level functions, and dig downward.  Make notes.  Look for comments along the way.  If you don't see comments, write some.  Absorb.  No one understands any system immediately, if you become one with the code, you too can be a master.</p><p>Nowadays, I'm the architect, and while there's still more code written before I got there 5 years ago than since I arrived, I understand just about all of it.  I've been programming for 20 years, and this makes the fourth time I've started with a million+ line system and ended up being one of the experts.</p><p>Patience, grasshopper.</p></htmltext>
<tokenext>Okay , first off , 40k lines is n't big , and unless they did a really horrible job of naming and organizing the parts , it should n't be hard to tackle .
I 'm dealing with a 1.5 million line assortment of legacy code , and while it 's taken a while to suss out , I have a pretty decent grasp of where everything is.It 's a Zen thing .
You look it over until you identify the top level units , then work your way down .
Most applications have a framework .
If you ca n't find a starting point , figure out which code is the most outward facing , read through the high level functions , and dig downward .
Make notes .
Look for comments along the way .
If you do n't see comments , write some .
Absorb. No one understands any system immediately , if you become one with the code , you too can be a master.Nowadays , I 'm the architect , and while there 's still more code written before I got there 5 years ago than since I arrived , I understand just about all of it .
I 've been programming for 20 years , and this makes the fourth time I 've started with a million + line system and ended up being one of the experts.Patience , grasshopper .</tokentext>
<sentencetext>Okay, first off, 40k lines isn't big, and unless they did a really horrible job of naming and organizing the parts, it shouldn't be hard to tackle.
I'm dealing with a 1.5 million line assortment of legacy code, and while it's taken a while to suss out, I have a pretty decent grasp of where everything is.It's a Zen thing.
You look it over until you identify the top level units, then work your way down.
Most applications have a framework.
If you can't find a starting point, figure out which code is the most outward facing, read through the high level functions, and dig downward.
Make notes.
Look for comments along the way.
If you don't see comments, write some.
Absorb.  No one understands any system immediately, if you become one with the code, you too can be a master.Nowadays, I'm the architect, and while there's still more code written before I got there 5 years ago than since I arrived, I understand just about all of it.
I've been programming for 20 years, and this makes the fourth time I've started with a million+ line system and ended up being one of the experts.Patience, grasshopper.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125300</id>
	<title>Re:That's incredibly small</title>
	<author>Anonymous</author>
	<datestamp>1266052620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Medium size is 250 to 750 million lines of code (one person can still understand how it all works). Big is 1 to 10 billion lines of code. Really big is &gt;10 billion.</p><p>I have worked on code bases of all of those sizes, and I like the medium size the best -- it's big enough to be interesting, and small enough that you can understand it all.</p><p>One that I've worked on (over 25 billion lines) is just too big for my tastes -- over 3 years to do a clean recompile is excessive.</p><p>---</p><p>Someone always have to be the biggest and the veriest, don't they?<nobr> <wbr></nobr>...</p></htmltext>
<tokenext>Medium size is 250 to 750 million lines of code ( one person can still understand how it all works ) .
Big is 1 to 10 billion lines of code .
Really big is &gt; 10 billion.I have worked on code bases of all of those sizes , and I like the medium size the best -- it 's big enough to be interesting , and small enough that you can understand it all.One that I 've worked on ( over 25 billion lines ) is just too big for my tastes -- over 3 years to do a clean recompile is excessive.---Someone always have to be the biggest and the veriest , do n't they ?
.. .</tokentext>
<sentencetext>Medium size is 250 to 750 million lines of code (one person can still understand how it all works).
Big is 1 to 10 billion lines of code.
Really big is &gt;10 billion.I have worked on code bases of all of those sizes, and I like the medium size the best -- it's big enough to be interesting, and small enough that you can understand it all.One that I've worked on (over 25 billion lines) is just too big for my tastes -- over 3 years to do a clean recompile is excessive.---Someone always have to be the biggest and the veriest, don't they?
...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126386</id>
	<title>Re:Not lots of code</title>
	<author>pz</author>
	<datestamp>1266070980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>First of all, 30-40,000 lines of code is not lots of code. Try, 250,000 of code.</p></div><p>Depends on the language.  For most of the popular languages (C / C++, Lisp, Scheme, Perl, Python, PHP, Ruby, Fortran, Matlab, Ada, ALGOL, whatever), you are spot-on.  For languages that have higher density (APL primary among them, but I might also include hand-written assembler), 30-40k lines is seriously daunting.</p></div>
	</htmltext>
<tokenext>First of all , 30-40,000 lines of code is not lots of code .
Try , 250,000 of code.Depends on the language .
For most of the popular languages ( C / C + + , Lisp , Scheme , Perl , Python , PHP , Ruby , Fortran , Matlab , Ada , ALGOL , whatever ) , you are spot-on .
For languages that have higher density ( APL primary among them , but I might also include hand-written assembler ) , 30-40k lines is seriously daunting .</tokentext>
<sentencetext>First of all, 30-40,000 lines of code is not lots of code.
Try, 250,000 of code.Depends on the language.
For most of the popular languages (C / C++, Lisp, Scheme, Perl, Python, PHP, Ruby, Fortran, Matlab, Ada, ALGOL, whatever), you are spot-on.
For languages that have higher density (APL primary among them, but I might also include hand-written assembler), 30-40k lines is seriously daunting.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122842</id>
	<title>Re:Not lots of code</title>
	<author>leoaloha</author>
	<datestamp>1265983320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>250000 is not a lot of code. Try over a million lines of C for train control of a transit authority. Purchased (read inherited) in escrow because management and the vendor got into a disagreement. The head software guru was upper class as far as I was concerned. I was the network guy. No documentation or very light. He had to live in the code but he was that kind of guy. My hat is off to him, I don't know how he did it</p></htmltext>
<tokenext>250000 is not a lot of code .
Try over a million lines of C for train control of a transit authority .
Purchased ( read inherited ) in escrow because management and the vendor got into a disagreement .
The head software guru was upper class as far as I was concerned .
I was the network guy .
No documentation or very light .
He had to live in the code but he was that kind of guy .
My hat is off to him , I do n't know how he did it</tokentext>
<sentencetext>250000 is not a lot of code.
Try over a million lines of C for train control of a transit authority.
Purchased (read inherited) in escrow because management and the vendor got into a disagreement.
The head software guru was upper class as far as I was concerned.
I was the network guy.
No documentation or very light.
He had to live in the code but he was that kind of guy.
My hat is off to him, I don't know how he did it</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125540</id>
	<title>Re:Not lots of code</title>
	<author>greg1104</author>
	<datestamp>1266057840000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Sure, if you only have a trivial 250K lines of code, I guess you can use crappy tools like Xcode and Visual Studio to maintain your project.  The rest of us have to use grown-up tools that look like this:</p><p>src$ find . -print | xargs wc | tail -n 1<br>
&nbsp; 1950894  7085675 56777966</p><p>There's only one way to learn your way around a new codebase, and the worst thing you can do is use a tool that aims to help with the job.  Want to know how stuff flows through the program?  Find where the program starts and draw the diagram yourself as you map it out.  What I do is find something that I think I need to change, and a clear goal for what change I want to make to it, then map out exactly how the program reaches that point.  You need to have a targeted goal to make progress with a stack of new code; just trying to read the whole thing or stare at diagrams of it won't teach you anything.  Put the sucker into version control, generate regression tests of its output, figure out how to build after making a trivial change, and then try making a small non-trivial one.  That's the only real way to learn how a program really works that internalizes enough of it into your brain that you can move upward to bigger maintenance tasks.</p><p>And, for the record, I would like to tell everyone who suggested using a debugger to trace through the code instead of figuring it out by inspection and experiments that you are all a bunch of pussies.  Good luck with that when the code breaks in production and you've got nothing but log files from the period loading up to the crash to work with.  If I can get a debugger to attach to a broken program when the problem exists, it is by definition a trivial problem to solve; if I can even get a backtrace of where the thing is stuck at when it goes bad that's automatically an easy one.  The only way to learn what you should be logging and defensively doing is by only relying on logs, assertions, and testing all the time--never a debugger.  Because when things go really wrong, you won't have your debugger to save your ass--but if you built in good testing and logging capabilities, they'll be there.</p></htmltext>
<tokenext>Sure , if you only have a trivial 250K lines of code , I guess you can use crappy tools like Xcode and Visual Studio to maintain your project .
The rest of us have to use grown-up tools that look like this : src $ find .
-print | xargs wc | tail -n 1   1950894 7085675 56777966There 's only one way to learn your way around a new codebase , and the worst thing you can do is use a tool that aims to help with the job .
Want to know how stuff flows through the program ?
Find where the program starts and draw the diagram yourself as you map it out .
What I do is find something that I think I need to change , and a clear goal for what change I want to make to it , then map out exactly how the program reaches that point .
You need to have a targeted goal to make progress with a stack of new code ; just trying to read the whole thing or stare at diagrams of it wo n't teach you anything .
Put the sucker into version control , generate regression tests of its output , figure out how to build after making a trivial change , and then try making a small non-trivial one .
That 's the only real way to learn how a program really works that internalizes enough of it into your brain that you can move upward to bigger maintenance tasks.And , for the record , I would like to tell everyone who suggested using a debugger to trace through the code instead of figuring it out by inspection and experiments that you are all a bunch of pussies .
Good luck with that when the code breaks in production and you 've got nothing but log files from the period loading up to the crash to work with .
If I can get a debugger to attach to a broken program when the problem exists , it is by definition a trivial problem to solve ; if I can even get a backtrace of where the thing is stuck at when it goes bad that 's automatically an easy one .
The only way to learn what you should be logging and defensively doing is by only relying on logs , assertions , and testing all the time--never a debugger .
Because when things go really wrong , you wo n't have your debugger to save your ass--but if you built in good testing and logging capabilities , they 'll be there .</tokentext>
<sentencetext>Sure, if you only have a trivial 250K lines of code, I guess you can use crappy tools like Xcode and Visual Studio to maintain your project.
The rest of us have to use grown-up tools that look like this:src$ find .
-print | xargs wc | tail -n 1
  1950894  7085675 56777966There's only one way to learn your way around a new codebase, and the worst thing you can do is use a tool that aims to help with the job.
Want to know how stuff flows through the program?
Find where the program starts and draw the diagram yourself as you map it out.
What I do is find something that I think I need to change, and a clear goal for what change I want to make to it, then map out exactly how the program reaches that point.
You need to have a targeted goal to make progress with a stack of new code; just trying to read the whole thing or stare at diagrams of it won't teach you anything.
Put the sucker into version control, generate regression tests of its output, figure out how to build after making a trivial change, and then try making a small non-trivial one.
That's the only real way to learn how a program really works that internalizes enough of it into your brain that you can move upward to bigger maintenance tasks.And, for the record, I would like to tell everyone who suggested using a debugger to trace through the code instead of figuring it out by inspection and experiments that you are all a bunch of pussies.
Good luck with that when the code breaks in production and you've got nothing but log files from the period loading up to the crash to work with.
If I can get a debugger to attach to a broken program when the problem exists, it is by definition a trivial problem to solve; if I can even get a backtrace of where the thing is stuck at when it goes bad that's automatically an easy one.
The only way to learn what you should be logging and defensively doing is by only relying on logs, assertions, and testing all the time--never a debugger.
Because when things go really wrong, you won't have your debugger to save your ass--but if you built in good testing and logging capabilities, they'll be there.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127604</id>
	<title>no reason to be discouraged</title>
	<author>alonsoac</author>
	<datestamp>1266081600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You shouldn't feel bad about not understanding easily all parts of a large code base. I've been programming for over 10 years and there are some systems that are still in production for more than 7 years and I am still in charge of maintenance. When I have to go back and change something it is very difficult, it is almost like someone else programmed it and it is tough to remember how things work. The problem is not that I am dumb now, the problem is I wasnt as good a programmer then and there was no budget/time for decent documentation.</p></htmltext>
<tokenext>You should n't feel bad about not understanding easily all parts of a large code base .
I 've been programming for over 10 years and there are some systems that are still in production for more than 7 years and I am still in charge of maintenance .
When I have to go back and change something it is very difficult , it is almost like someone else programmed it and it is tough to remember how things work .
The problem is not that I am dumb now , the problem is I wasnt as good a programmer then and there was no budget/time for decent documentation .</tokentext>
<sentencetext>You shouldn't feel bad about not understanding easily all parts of a large code base.
I've been programming for over 10 years and there are some systems that are still in production for more than 7 years and I am still in charge of maintenance.
When I have to go back and change something it is very difficult, it is almost like someone else programmed it and it is tough to remember how things work.
The problem is not that I am dumb now, the problem is I wasnt as good a programmer then and there was no budget/time for decent documentation.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123098</id>
	<title>Fix small bugs</title>
	<author>Midnight Thunder</author>
	<datestamp>1265985000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I have been given projects of this nature and the best approach is to document what is obvious and then use bug fixing as a way in to the code. While it won't give you a complete picture, it should help you understand what is immediately important, and serve as guide posts for knowing more in the future. Generally I try not to spend too much time trying to understand everything, since its a waste of time, unless that knowledge is guaranteed to serve you - sometimes the client just wants it be tweaked once in a while, so it probably is not worth the time if you can't charge them for it.</p><p>To sum up: give yourself a general picture and then concentrate on the details only when it matters.</p></htmltext>
<tokenext>I have been given projects of this nature and the best approach is to document what is obvious and then use bug fixing as a way in to the code .
While it wo n't give you a complete picture , it should help you understand what is immediately important , and serve as guide posts for knowing more in the future .
Generally I try not to spend too much time trying to understand everything , since its a waste of time , unless that knowledge is guaranteed to serve you - sometimes the client just wants it be tweaked once in a while , so it probably is not worth the time if you ca n't charge them for it.To sum up : give yourself a general picture and then concentrate on the details only when it matters .</tokentext>
<sentencetext>I have been given projects of this nature and the best approach is to document what is obvious and then use bug fixing as a way in to the code.
While it won't give you a complete picture, it should help you understand what is immediately important, and serve as guide posts for knowing more in the future.
Generally I try not to spend too much time trying to understand everything, since its a waste of time, unless that knowledge is guaranteed to serve you - sometimes the client just wants it be tweaked once in a while, so it probably is not worth the time if you can't charge them for it.To sum up: give yourself a general picture and then concentrate on the details only when it matters.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128526</id>
	<title>Source Insight Code Browser</title>
	<author>Anonymous</author>
	<datestamp>1266088500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I work at a major software company with millions of lines of code in our software repository. A lot of the developers here favor Source Insight www.sourceinsight.com/ It is an excellent code browser for complex code bases.</p></htmltext>
<tokenext>I work at a major software company with millions of lines of code in our software repository .
A lot of the developers here favor Source Insight www.sourceinsight.com/ It is an excellent code browser for complex code bases .</tokentext>
<sentencetext>I work at a major software company with millions of lines of code in our software repository.
A lot of the developers here favor Source Insight www.sourceinsight.com/ It is an excellent code browser for complex code bases.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125808</id>
	<title>Re:Tried and True</title>
	<author>Anonymous</author>
	<datestamp>1266062400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Sorry, but what killed Netscape?<br>Wasn't that that they wanted to rewrite everything to Java while Microsoft added features instead?</p><p>Rewriting might be a good idea but it all depends on the complexity of the solution and the main reasons.<br>Rewriting in a faster language (i.e. compiled instead of parsed), x64 instead of x32 or whatever might be the reason; however I'm not very sure that "not being able to read the other guys' code" is a good reason.</p></htmltext>
<tokenext>Sorry , but what killed Netscape ? Was n't that that they wanted to rewrite everything to Java while Microsoft added features instead ? Rewriting might be a good idea but it all depends on the complexity of the solution and the main reasons.Rewriting in a faster language ( i.e .
compiled instead of parsed ) , x64 instead of x32 or whatever might be the reason ; however I 'm not very sure that " not being able to read the other guys ' code " is a good reason .</tokentext>
<sentencetext>Sorry, but what killed Netscape?Wasn't that that they wanted to rewrite everything to Java while Microsoft added features instead?Rewriting might be a good idea but it all depends on the complexity of the solution and the main reasons.Rewriting in a faster language (i.e.
compiled instead of parsed), x64 instead of x32 or whatever might be the reason; however I'm not very sure that "not being able to read the other guys' code" is a good reason.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124262</id>
	<title>find / grep / glimpse</title>
	<author>amiga500</author>
	<datestamp>1265995260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>On Windows I install cygwin, so I can execute grep.  I use the following bash function to help me search code:<blockquote><div><p> <tt>ffind ()<br>{<br> find . -name ".svn" -prune -o -name "CVS" -prune -o -name ".hg" -prune -o -exec grep --color=auto "$@" {} +<br>}</tt></p></div> </blockquote><p>For larger code bases, I use the command line version of glimpse to search through the code.  While there are a few open source code search engines, I find glimpse with a few <a href="http://www.theeggeadventure.com/wikimedia/index.php/Colorize\_Glimpse" title="theeggeadventure.com" rel="nofollow">formatting scripts</a> [theeggeadventure.com] works just fine.</p></div>
	</htmltext>
<tokenext>On Windows I install cygwin , so I can execute grep .
I use the following bash function to help me search code : ffind ( ) { find .
-name " .svn " -prune -o -name " CVS " -prune -o -name " .hg " -prune -o -exec grep --color = auto " $ @ " { } + } For larger code bases , I use the command line version of glimpse to search through the code .
While there are a few open source code search engines , I find glimpse with a few formatting scripts [ theeggeadventure.com ] works just fine .</tokentext>
<sentencetext>On Windows I install cygwin, so I can execute grep.
I use the following bash function to help me search code: ffind (){ find .
-name ".svn" -prune -o -name "CVS" -prune -o -name ".hg" -prune -o -exec grep --color=auto "$@" {} +} For larger code bases, I use the command line version of glimpse to search through the code.
While there are a few open source code search engines, I find glimpse with a few formatting scripts [theeggeadventure.com] works just fine.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124792</id>
	<title>Oh boo bloody hoo</title>
	<author>Anonymous</author>
	<datestamp>1266001560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Oh no, there's no documentation...oh wait yes there is...it's on this single sheet of A4....in swahili.  Perfectly normal introduction to the new work environment in my experience.  Grow a set, and hope the guy who wrote it wasn't actually a genius because it's a hell of lot easier fixing the fuckups of regular developers.</p></htmltext>
<tokenext>Oh no , there 's no documentation...oh wait yes there is...it 's on this single sheet of A4....in swahili .
Perfectly normal introduction to the new work environment in my experience .
Grow a set , and hope the guy who wrote it was n't actually a genius because it 's a hell of lot easier fixing the fuckups of regular developers .</tokentext>
<sentencetext>Oh no, there's no documentation...oh wait yes there is...it's on this single sheet of A4....in swahili.
Perfectly normal introduction to the new work environment in my experience.
Grow a set, and hope the guy who wrote it wasn't actually a genius because it's a hell of lot easier fixing the fuckups of regular developers.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122354</id>
	<title>Trace sessions and time</title>
	<author>Anonymous</author>
	<datestamp>1265980920000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>
I'll echo some earlier comments.
</p><p>
Set up an execution environment with debugger, and run several typical scenarios and trace them with debugger.   Get the feel of the big-picture execution scenarios/paths.
</p><p>
It will take time for your brains to get comfortable with it, though.  And the details, when you look into them, will throw odd stuff at you.  But that's the nature of our work.</p></htmltext>
<tokenext>I 'll echo some earlier comments .
Set up an execution environment with debugger , and run several typical scenarios and trace them with debugger .
Get the feel of the big-picture execution scenarios/paths .
It will take time for your brains to get comfortable with it , though .
And the details , when you look into them , will throw odd stuff at you .
But that 's the nature of our work .</tokentext>
<sentencetext>
I'll echo some earlier comments.
Set up an execution environment with debugger, and run several typical scenarios and trace them with debugger.
Get the feel of the big-picture execution scenarios/paths.
It will take time for your brains to get comfortable with it, though.
And the details, when you look into them, will throw odd stuff at you.
But that's the nature of our work.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125252</id>
	<title>Re:Not at all.</title>
	<author>mcrbids</author>
	<datestamp>1266051600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I find that if any programmer writes code in such a way where it's too complex for others to follow, he's the one who's a moron.</p> </div><p>There. Fixed that for you! Pure genius is pure simplicity. Anybody of average intelligence can come up with a a complex answer to a complex problem. But it's somebody of far more intelligence who can come up with a simple answer to a complex problem!</p><p>Many problem are, at first look, very complex, but, when given sufficient genius, succumb to the genius of simplicity. And even when the problem is very complex, the code used to solve it should be easily read and understood!</p></div>
	</htmltext>
<tokenext>I find that if any programmer writes code in such a way where it 's too complex for others to follow , he 's the one who 's a moron .
There. Fixed that for you !
Pure genius is pure simplicity .
Anybody of average intelligence can come up with a a complex answer to a complex problem .
But it 's somebody of far more intelligence who can come up with a simple answer to a complex problem ! Many problem are , at first look , very complex , but , when given sufficient genius , succumb to the genius of simplicity .
And even when the problem is very complex , the code used to solve it should be easily read and understood !</tokentext>
<sentencetext>I find that if any programmer writes code in such a way where it's too complex for others to follow, he's the one who's a moron.
There. Fixed that for you!
Pure genius is pure simplicity.
Anybody of average intelligence can come up with a a complex answer to a complex problem.
But it's somebody of far more intelligence who can come up with a simple answer to a complex problem!Many problem are, at first look, very complex, but, when given sufficient genius, succumb to the genius of simplicity.
And even when the problem is very complex, the code used to solve it should be easily read and understood!
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122286</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123766</id>
	<title>Unit tests</title>
	<author>steveha</author>
	<datestamp>1265990460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The first thing you do is get everything under source code control.  If it already is, good.  You should have a clearly-marked branch that shows where you started hacking on it, so you can easily tell what pre-dates you.</p><p>And by the way, I highly recommend the Git version control system.  Among its many great features, it lets you use a version control system that is only on one computer, and get things right <em>before</em> you "push" your changes up to the group server.  Thus you have the full power of a version control system, and the freedom to use it, without worrying about breaking things for anyone else.  Best practice use of Git: on your local machine, make a new "branch", check out the branch, and do your experimenting in that.  If you suddenly, urgently need to fix a bug in the main code, you switch away from your branch to the main branch, do what you must, then switch back to your new branch when convenient.  If the branch doesn't work out, you can just delete it.  If it works out, you can merge it.  (By the way, the above is true of any "distributed" version control system, not just Git.)</p><p>Several others have told you to start with unit tests.  If the code base already has a set, start by studying them.  If the code base does not have unit tests, write some.</p><p>Presumably you inherited a working system.  The unit tests will put a definition on what "working" currently means.  When you change the code, if you introduce a bug, you want one or more of your unit tests to detect the bug and let you know, <em>before</em> you share your updated code with anyone else.  Unit tests are some work to set up, but they provide huge peace of mind for you once you have a good set.</p><p>And, whenever you are asked to fix a bug (whether you caused it or not), you add a unit test that tests for that bug.  Over time the unit tests will become more and more valuable.</p><p>I also second this advice by <a href="http://ask.slashdot.org/comments.pl?sid=1548488&amp;cid=31123202" title="slashdot.org">npsimons</a> [slashdot.org].  Try various automated tools that check for memory leaks and such.  If they find bugs, fix the bugs (in your private branch) and then make sure that the fixed version passes the unit tests.  You will learn the code base as you find and fix the bugs, and you will improve the stability of the code.</p><p>If you find any particularly important variables or data structures, you might want to add some assert statements that check those values in the Debug build.  In the Release build, the asserts don't even get compiled in, so they are "free", but if you run the debug build, the asserts can find bugs for you.  For example, if you have a crucial handle to some resource, and the handle is getting clobbered, put asserts all through the code that assert that the handle hasn't been clobbered yet, then run the debug build and see where the assert fires.  This may not save you time if the clobbering bug only happens once, but you never take the asserts out, so the asserts can find a bug for you if you accidentally re-introduce the bug.  (Note that this implies you will want to run your Debug build under the unit tests, in addition to your Release build.  The asserts can fire and show you where a bug is, but you need the code to run, and if you have good code coverage from your unit tests, that will happen.)</p><p>Good luck.</p><p>steveha</p></htmltext>
<tokenext>The first thing you do is get everything under source code control .
If it already is , good .
You should have a clearly-marked branch that shows where you started hacking on it , so you can easily tell what pre-dates you.And by the way , I highly recommend the Git version control system .
Among its many great features , it lets you use a version control system that is only on one computer , and get things right before you " push " your changes up to the group server .
Thus you have the full power of a version control system , and the freedom to use it , without worrying about breaking things for anyone else .
Best practice use of Git : on your local machine , make a new " branch " , check out the branch , and do your experimenting in that .
If you suddenly , urgently need to fix a bug in the main code , you switch away from your branch to the main branch , do what you must , then switch back to your new branch when convenient .
If the branch does n't work out , you can just delete it .
If it works out , you can merge it .
( By the way , the above is true of any " distributed " version control system , not just Git .
) Several others have told you to start with unit tests .
If the code base already has a set , start by studying them .
If the code base does not have unit tests , write some.Presumably you inherited a working system .
The unit tests will put a definition on what " working " currently means .
When you change the code , if you introduce a bug , you want one or more of your unit tests to detect the bug and let you know , before you share your updated code with anyone else .
Unit tests are some work to set up , but they provide huge peace of mind for you once you have a good set.And , whenever you are asked to fix a bug ( whether you caused it or not ) , you add a unit test that tests for that bug .
Over time the unit tests will become more and more valuable.I also second this advice by npsimons [ slashdot.org ] .
Try various automated tools that check for memory leaks and such .
If they find bugs , fix the bugs ( in your private branch ) and then make sure that the fixed version passes the unit tests .
You will learn the code base as you find and fix the bugs , and you will improve the stability of the code.If you find any particularly important variables or data structures , you might want to add some assert statements that check those values in the Debug build .
In the Release build , the asserts do n't even get compiled in , so they are " free " , but if you run the debug build , the asserts can find bugs for you .
For example , if you have a crucial handle to some resource , and the handle is getting clobbered , put asserts all through the code that assert that the handle has n't been clobbered yet , then run the debug build and see where the assert fires .
This may not save you time if the clobbering bug only happens once , but you never take the asserts out , so the asserts can find a bug for you if you accidentally re-introduce the bug .
( Note that this implies you will want to run your Debug build under the unit tests , in addition to your Release build .
The asserts can fire and show you where a bug is , but you need the code to run , and if you have good code coverage from your unit tests , that will happen .
) Good luck.steveha</tokentext>
<sentencetext>The first thing you do is get everything under source code control.
If it already is, good.
You should have a clearly-marked branch that shows where you started hacking on it, so you can easily tell what pre-dates you.And by the way, I highly recommend the Git version control system.
Among its many great features, it lets you use a version control system that is only on one computer, and get things right before you "push" your changes up to the group server.
Thus you have the full power of a version control system, and the freedom to use it, without worrying about breaking things for anyone else.
Best practice use of Git: on your local machine, make a new "branch", check out the branch, and do your experimenting in that.
If you suddenly, urgently need to fix a bug in the main code, you switch away from your branch to the main branch, do what you must, then switch back to your new branch when convenient.
If the branch doesn't work out, you can just delete it.
If it works out, you can merge it.
(By the way, the above is true of any "distributed" version control system, not just Git.
)Several others have told you to start with unit tests.
If the code base already has a set, start by studying them.
If the code base does not have unit tests, write some.Presumably you inherited a working system.
The unit tests will put a definition on what "working" currently means.
When you change the code, if you introduce a bug, you want one or more of your unit tests to detect the bug and let you know, before you share your updated code with anyone else.
Unit tests are some work to set up, but they provide huge peace of mind for you once you have a good set.And, whenever you are asked to fix a bug (whether you caused it or not), you add a unit test that tests for that bug.
Over time the unit tests will become more and more valuable.I also second this advice by npsimons [slashdot.org].
Try various automated tools that check for memory leaks and such.
If they find bugs, fix the bugs (in your private branch) and then make sure that the fixed version passes the unit tests.
You will learn the code base as you find and fix the bugs, and you will improve the stability of the code.If you find any particularly important variables or data structures, you might want to add some assert statements that check those values in the Debug build.
In the Release build, the asserts don't even get compiled in, so they are "free", but if you run the debug build, the asserts can find bugs for you.
For example, if you have a crucial handle to some resource, and the handle is getting clobbered, put asserts all through the code that assert that the handle hasn't been clobbered yet, then run the debug build and see where the assert fires.
This may not save you time if the clobbering bug only happens once, but you never take the asserts out, so the asserts can find a bug for you if you accidentally re-introduce the bug.
(Note that this implies you will want to run your Debug build under the unit tests, in addition to your Release build.
The asserts can fire and show you where a bug is, but you need the code to run, and if you have good code coverage from your unit tests, that will happen.
)Good luck.steveha</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31130202</id>
	<title>May be of help: FAMOOS Reengineering Handbook</title>
	<author>Anonymous</author>
	<datestamp>1266058200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>May I suggest reviewing the FAMOOS Object Oriented Reengineering Handbook. Ignore the<br>the age (1999) and consider the approaches.<br>FAMOOS Handbook: http://scg.unibe.ch/download/projectreports/FamoosHandbook.pdf</p></htmltext>
<tokenext>May I suggest reviewing the FAMOOS Object Oriented Reengineering Handbook .
Ignore thethe age ( 1999 ) and consider the approaches.FAMOOS Handbook : http : //scg.unibe.ch/download/projectreports/FamoosHandbook.pdf</tokentext>
<sentencetext>May I suggest reviewing the FAMOOS Object Oriented Reengineering Handbook.
Ignore thethe age (1999) and consider the approaches.FAMOOS Handbook: http://scg.unibe.ch/download/projectreports/FamoosHandbook.pdf</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122940</id>
	<title>Am I weird...?</title>
	<author>chewthreetimes</author>
	<datestamp>1265984040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>...because I actually enjoy going through someone else's code? I roll up my sleeves and, using print statements and/or a debugger, I diagram object relationships, flow, data structures...anything I can think of. It's like figuring out a puzzle.

Of course, I've had the luck of never inheriting a total pile of crap. But give me anything from not-perfect-but-serviceable on up, and I not only can deal, but I'll have a good time doing so.</htmltext>
<tokenext>...because I actually enjoy going through someone else 's code ?
I roll up my sleeves and , using print statements and/or a debugger , I diagram object relationships , flow , data structures...anything I can think of .
It 's like figuring out a puzzle .
Of course , I 've had the luck of never inheriting a total pile of crap .
But give me anything from not-perfect-but-serviceable on up , and I not only can deal , but I 'll have a good time doing so .</tokentext>
<sentencetext>...because I actually enjoy going through someone else's code?
I roll up my sleeves and, using print statements and/or a debugger, I diagram object relationships, flow, data structures...anything I can think of.
It's like figuring out a puzzle.
Of course, I've had the luck of never inheriting a total pile of crap.
But give me anything from not-perfect-but-serviceable on up, and I not only can deal, but I'll have a good time doing so.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126414</id>
	<title>Re:It depends on the language</title>
	<author>Anonymous</author>
	<datestamp>1266071400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>No... if its Perl or VB code you inherit you should leap for joy!  If its 2.5 MILLION lines of COBOL code written in the 1980's to access an IMS database and then 'bridged' to continue its original IMS transactions patched so they are really accessing DB2 database, then proceed with 'self-immolation as a first step'.</p></htmltext>
<tokenext>No... if its Perl or VB code you inherit you should leap for joy !
If its 2.5 MILLION lines of COBOL code written in the 1980 's to access an IMS database and then 'bridged ' to continue its original IMS transactions patched so they are really accessing DB2 database , then proceed with 'self-immolation as a first step' .</tokentext>
<sentencetext>No... if its Perl or VB code you inherit you should leap for joy!
If its 2.5 MILLION lines of COBOL code written in the 1980's to access an IMS database and then 'bridged' to continue its original IMS transactions patched so they are really accessing DB2 database, then proceed with 'self-immolation as a first step'.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122256</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122304</id>
	<title>use a debugger</title>
	<author>Anonymous</author>
	<datestamp>1265980680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The best way to figure out how the code does action X is to run it under a debugger while it does the action, inspecting how the data structures in the program change, setting breakpoints where the decisions are made to see what happens, etc.  You get to see dynamically what the program is doing step by step with the computer keeping track of it for you, instead of puzzling it out from a static listing.  Running the code that way is a much faster way to gain understanding than simply reading the code.</p></htmltext>
<tokenext>The best way to figure out how the code does action X is to run it under a debugger while it does the action , inspecting how the data structures in the program change , setting breakpoints where the decisions are made to see what happens , etc .
You get to see dynamically what the program is doing step by step with the computer keeping track of it for you , instead of puzzling it out from a static listing .
Running the code that way is a much faster way to gain understanding than simply reading the code .</tokentext>
<sentencetext>The best way to figure out how the code does action X is to run it under a debugger while it does the action, inspecting how the data structures in the program change, setting breakpoints where the decisions are made to see what happens, etc.
You get to see dynamically what the program is doing step by step with the computer keeping track of it for you, instead of puzzling it out from a static listing.
Running the code that way is a much faster way to gain understanding than simply reading the code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125884</id>
	<title>codelines/h from BMW</title>
	<author>thetinytoon</author>
	<datestamp>1266063540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Already stated, but my 2 cents:
- use a good IDE with fast referencing possibility (e.g. right-click on a function call =&gt; "follow")
- use a profiler to see a flowchart or UML for a high level overview
- start commenting the classes and refactor their names if unclear. There are nice tools out there (depending on the language), which create DocBlocks for everything first and then you can use DoxyGen to generate a nice overview over everything.

And about the question of how bad you are: one of my IT lecturers had worked at BMW and they had made a test on the efficiency of their programmers on new code and on code written by other developers.
When the same developer had to extend or change code of other developers, he was a hundred times slower than when he would code on his own himself. That was around 2001, if I'm not mistaken.</htmltext>
<tokenext>Already stated , but my 2 cents : - use a good IDE with fast referencing possibility ( e.g .
right-click on a function call = &gt; " follow " ) - use a profiler to see a flowchart or UML for a high level overview - start commenting the classes and refactor their names if unclear .
There are nice tools out there ( depending on the language ) , which create DocBlocks for everything first and then you can use DoxyGen to generate a nice overview over everything .
And about the question of how bad you are : one of my IT lecturers had worked at BMW and they had made a test on the efficiency of their programmers on new code and on code written by other developers .
When the same developer had to extend or change code of other developers , he was a hundred times slower than when he would code on his own himself .
That was around 2001 , if I 'm not mistaken .</tokentext>
<sentencetext>Already stated, but my 2 cents:
- use a good IDE with fast referencing possibility (e.g.
right-click on a function call =&gt; "follow")
- use a profiler to see a flowchart or UML for a high level overview
- start commenting the classes and refactor their names if unclear.
There are nice tools out there (depending on the language), which create DocBlocks for everything first and then you can use DoxyGen to generate a nice overview over everything.
And about the question of how bad you are: one of my IT lecturers had worked at BMW and they had made a test on the efficiency of their programmers on new code and on code written by other developers.
When the same developer had to extend or change code of other developers, he was a hundred times slower than when he would code on his own himself.
That was around 2001, if I'm not mistaken.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31197272</id>
	<title>That's legacy code</title>
	<author>Anonymous</author>
	<datestamp>1266578220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You need to grab a copy of "Working Effectively with Legacy Code" by Michael Feathers and read it carefully. That will help.</p><p>And yes, 40kloc is not a lot at all (unless these aren't huge perl regular expressions *evil grin*).</p></htmltext>
<tokenext>You need to grab a copy of " Working Effectively with Legacy Code " by Michael Feathers and read it carefully .
That will help.And yes , 40kloc is not a lot at all ( unless these are n't huge perl regular expressions * evil grin * ) .</tokentext>
<sentencetext>You need to grab a copy of "Working Effectively with Legacy Code" by Michael Feathers and read it carefully.
That will help.And yes, 40kloc is not a lot at all (unless these aren't huge perl regular expressions *evil grin*).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123272</id>
	<title>Re:Not lots of code</title>
	<author>Anonymous</author>
	<datestamp>1265986260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>250k isn't a lot either; try a million or two.</p><p>No matter *how* it's written, a million lines of code (non-comment lines, mind you) is a lot.</p></htmltext>
<tokenext>250k is n't a lot either ; try a million or two.No matter * how * it 's written , a million lines of code ( non-comment lines , mind you ) is a lot .</tokentext>
<sentencetext>250k isn't a lot either; try a million or two.No matter *how* it's written, a million lines of code (non-comment lines, mind you) is a lot.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126708</id>
	<title>Asked before. Answer: use tools ...</title>
	<author>golodh</author>
	<datestamp>1266074220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Approximately the same question was asked before and received (in my opinion very good) answers in this thread:
<a href="http://ask.slashdot.org/askslashdot/08/01/18/1554257.shtml" title="slashdot.org">http://ask.slashdot.org/askslashdot/08/01/18/1554257.shtml</a> [slashdot.org]
<p>
Specifically limiting yourself to "reading code" and relying the likes of "grep" is (as far as I'm concerned) behaviour of a Code Monkey, not a Software Engineer.</p></htmltext>
<tokenext>Approximately the same question was asked before and received ( in my opinion very good ) answers in this thread : http : //ask.slashdot.org/askslashdot/08/01/18/1554257.shtml [ slashdot.org ] Specifically limiting yourself to " reading code " and relying the likes of " grep " is ( as far as I 'm concerned ) behaviour of a Code Monkey , not a Software Engineer .</tokentext>
<sentencetext>Approximately the same question was asked before and received (in my opinion very good) answers in this thread:
http://ask.slashdot.org/askslashdot/08/01/18/1554257.shtml [slashdot.org]

Specifically limiting yourself to "reading code" and relying the likes of "grep" is (as far as I'm concerned) behaviour of a Code Monkey, not a Software Engineer.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123138</id>
	<title>Re:Tried and True</title>
	<author>Anonymous</author>
	<datestamp>1265985240000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>These projects invariably have lots of tiny gotchas that you're going to steamroll in your effort to rewrite it.  See <a href="http://www.joelonsoftware.com/articles/fog0000000069.html" title="joelonsoftware.com">Joel on Software on this</a> [joelonsoftware.com].</htmltext>
<tokenext>These projects invariably have lots of tiny gotchas that you 're going to steamroll in your effort to rewrite it .
See Joel on Software on this [ joelonsoftware.com ] .</tokentext>
<sentencetext>These projects invariably have lots of tiny gotchas that you're going to steamroll in your effort to rewrite it.
See Joel on Software on this [joelonsoftware.com].</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31133834</id>
	<title>Re:That's small</title>
	<author>Anonymous</author>
	<datestamp>1266152940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Medium size is 250 to 750 thousand lines of code (one person can still understand how it all works). Big is 1 to 10 million lines of code. Really big is &gt;10 million.</p><p>I have worked on code bases of all of those sizes, and I like the medium size the best -- it's big enough to be interesting, and small enough that you can understand it all.</p><p>One that I've worked on (over 25 million lines) is just too big for my tastes -- over 3 hours to do a clean recompile is excessive.</p></div><p>25 million lines of code that you inherited and worked with by yourself? Okaaaaay...</p></div>
	</htmltext>
<tokenext>Medium size is 250 to 750 thousand lines of code ( one person can still understand how it all works ) .
Big is 1 to 10 million lines of code .
Really big is &gt; 10 million.I have worked on code bases of all of those sizes , and I like the medium size the best -- it 's big enough to be interesting , and small enough that you can understand it all.One that I 've worked on ( over 25 million lines ) is just too big for my tastes -- over 3 hours to do a clean recompile is excessive.25 million lines of code that you inherited and worked with by yourself ?
Okaaaaay.. .</tokentext>
<sentencetext>Medium size is 250 to 750 thousand lines of code (one person can still understand how it all works).
Big is 1 to 10 million lines of code.
Really big is &gt;10 million.I have worked on code bases of all of those sizes, and I like the medium size the best -- it's big enough to be interesting, and small enough that you can understand it all.One that I've worked on (over 25 million lines) is just too big for my tastes -- over 3 hours to do a clean recompile is excessive.25 million lines of code that you inherited and worked with by yourself?
Okaaaaay...
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122404</id>
	<title>2000 lines can be enough</title>
	<author>sugarmotor</author>
	<datestamp>1265981220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>2000 lines can be enough to throw you off!</p><p>I think it is just like learning anything. Keep at it.</p><p>The most important thing is whether you have an efficient way to<br>look at what effect any changes have that you may make. Any effort you put into<br>that is probably not going to be wasted. (Might be unit tests? Sounds like they did not come with the code)</p><p>Stephan</p></htmltext>
<tokenext>2000 lines can be enough to throw you off ! I think it is just like learning anything .
Keep at it.The most important thing is whether you have an efficient way tolook at what effect any changes have that you may make .
Any effort you put intothat is probably not going to be wasted .
( Might be unit tests ?
Sounds like they did not come with the code ) Stephan</tokentext>
<sentencetext>2000 lines can be enough to throw you off!I think it is just like learning anything.
Keep at it.The most important thing is whether you have an efficient way tolook at what effect any changes have that you may make.
Any effort you put intothat is probably not going to be wasted.
(Might be unit tests?
Sounds like they did not come with the code)Stephan</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124526</id>
	<title>Re:That's small</title>
	<author>Anonymous</author>
	<datestamp>1265998380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I can't help but agree with this annotation of medium and large. 30-40 KLOC is feasible to go through and exhaustively document the program's structure and core algorithms. While an in depth understanding can take a few months to grasp, a thumbnail sketch can be feasibly generated in a week.</p><p>Two tips: (1) spend time running it in a debugger stepping through the code, and (2) break it. It can be hard to understand some things by watching them work correctly. Intentionally breaking things helps expose assumptions that were made by previous programmers. Figuring out how to fix what you broke forces you to understand what's really going on in the code base.</p></htmltext>
<tokenext>I ca n't help but agree with this annotation of medium and large .
30-40 KLOC is feasible to go through and exhaustively document the program 's structure and core algorithms .
While an in depth understanding can take a few months to grasp , a thumbnail sketch can be feasibly generated in a week.Two tips : ( 1 ) spend time running it in a debugger stepping through the code , and ( 2 ) break it .
It can be hard to understand some things by watching them work correctly .
Intentionally breaking things helps expose assumptions that were made by previous programmers .
Figuring out how to fix what you broke forces you to understand what 's really going on in the code base .</tokentext>
<sentencetext>I can't help but agree with this annotation of medium and large.
30-40 KLOC is feasible to go through and exhaustively document the program's structure and core algorithms.
While an in depth understanding can take a few months to grasp, a thumbnail sketch can be feasibly generated in a week.Two tips: (1) spend time running it in a debugger stepping through the code, and (2) break it.
It can be hard to understand some things by watching them work correctly.
Intentionally breaking things helps expose assumptions that were made by previous programmers.
Figuring out how to fix what you broke forces you to understand what's really going on in the code base.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126980</id>
	<title>Have you tried Krugle?</title>
	<author>ClosedLoop</author>
	<datestamp>1266076980000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>About a year ago, I took advantage of my employer's "Innovation" program to promote our internal use of a code-search tool called <a href="http://www.krugle.com/" title="krugle.com" rel="nofollow">Krugle</a> [krugle.com].  I took point in contacting Krugle, arranged for a free demo period, and administered the demo on a machine in our network.  Of course, I fell afoul of the "Innovation" program, because my version of "Innovation" was something to help us develop a better product.  In fact, the program was intended to find a better color for the box, so my Krugle effort was lost on them, but hey I'm not bitter....
Ok, on to the point.  I got a dozen developers to participate in the evaluation of a Krugle copy running inside our firewall.  It indexed millions of lines of legacy code, organized across a dozen different projects.  In my opinion, and I believe the majority of other evaluators as well, being able to search our code exhaustively was a major benefit in getting "arms around" the code base.  It changes your outlook.  You start asking questions like
<ul>
  <li>Where are all the places that a different component calls this API?</li><li>What the heck does error code 4872339 mean, and who generates it?</li><li>How many derived classes override this virtual function?</li></ul><p>
If you surf on over to <a href="http://www.krugle.com/" title="krugle.com" rel="nofollow">Krugle.com</a> [krugle.com], you will see that they now offer a free evaluation copy as a standard product.  If you want to get a feeling for what can be done with the tool, just check out <a href="http://www.krugle.org/" title="krugle.org" rel="nofollow">Krugle.org</a> [krugle.org], where lots of open-source projects are indexed online.  I would definitely recommend using the free evaluation tool as a way of speeding your high-level understanding of any new-to-you code base.</p></htmltext>
<tokenext>About a year ago , I took advantage of my employer 's " Innovation " program to promote our internal use of a code-search tool called Krugle [ krugle.com ] .
I took point in contacting Krugle , arranged for a free demo period , and administered the demo on a machine in our network .
Of course , I fell afoul of the " Innovation " program , because my version of " Innovation " was something to help us develop a better product .
In fact , the program was intended to find a better color for the box , so my Krugle effort was lost on them , but hey I 'm not bitter... . Ok , on to the point .
I got a dozen developers to participate in the evaluation of a Krugle copy running inside our firewall .
It indexed millions of lines of legacy code , organized across a dozen different projects .
In my opinion , and I believe the majority of other evaluators as well , being able to search our code exhaustively was a major benefit in getting " arms around " the code base .
It changes your outlook .
You start asking questions like Where are all the places that a different component calls this API ? What the heck does error code 4872339 mean , and who generates it ? How many derived classes override this virtual function ?
If you surf on over to Krugle.com [ krugle.com ] , you will see that they now offer a free evaluation copy as a standard product .
If you want to get a feeling for what can be done with the tool , just check out Krugle.org [ krugle.org ] , where lots of open-source projects are indexed online .
I would definitely recommend using the free evaluation tool as a way of speeding your high-level understanding of any new-to-you code base .</tokentext>
<sentencetext>About a year ago, I took advantage of my employer's "Innovation" program to promote our internal use of a code-search tool called Krugle [krugle.com].
I took point in contacting Krugle, arranged for a free demo period, and administered the demo on a machine in our network.
Of course, I fell afoul of the "Innovation" program, because my version of "Innovation" was something to help us develop a better product.
In fact, the program was intended to find a better color for the box, so my Krugle effort was lost on them, but hey I'm not bitter....
Ok, on to the point.
I got a dozen developers to participate in the evaluation of a Krugle copy running inside our firewall.
It indexed millions of lines of legacy code, organized across a dozen different projects.
In my opinion, and I believe the majority of other evaluators as well, being able to search our code exhaustively was a major benefit in getting "arms around" the code base.
It changes your outlook.
You start asking questions like

  Where are all the places that a different component calls this API?What the heck does error code 4872339 mean, and who generates it?How many derived classes override this virtual function?
If you surf on over to Krugle.com [krugle.com], you will see that they now offer a free evaluation copy as a standard product.
If you want to get a feeling for what can be done with the tool, just check out Krugle.org [krugle.org], where lots of open-source projects are indexed online.
I would definitely recommend using the free evaluation tool as a way of speeding your high-level understanding of any new-to-you code base.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122498</id>
	<title>Read the source!</title>
	<author>Deflatamouse!</author>
	<datestamp>1265981640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Seriously... if there is a lack of documentation, then you just have to start reading the source code, starting at main(). Then look at each object and read its constructors.</p><p>And start documenting it. Add comments in the code, create inheritance diagrams and sequence diagrams.</p><p>It will be tedious but you will come out of it a better programmer.</p></htmltext>
<tokenext>Seriously... if there is a lack of documentation , then you just have to start reading the source code , starting at main ( ) .
Then look at each object and read its constructors.And start documenting it .
Add comments in the code , create inheritance diagrams and sequence diagrams.It will be tedious but you will come out of it a better programmer .</tokentext>
<sentencetext>Seriously... if there is a lack of documentation, then you just have to start reading the source code, starting at main().
Then look at each object and read its constructors.And start documenting it.
Add comments in the code, create inheritance diagrams and sequence diagrams.It will be tedious but you will come out of it a better programmer.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125044</id>
	<title>Re:My Dick is Bigger than Your 250,000 lines of co</title>
	<author>Lock Limit Down</author>
	<datestamp>1266004620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My advice to you is to start drinking heavily.</p><p>A lot of good advice above, but there's a political aspect to this which is very important.</p><p>How you do will very much depend on the expectations that management has. They very often assume maintaining code is much easier than writing it in the first place which is of course the exact opposite of the reality. Make sure you talk with them about expectations up front, about how soon they expect you to be competent in the code.</p><p>In all honesty, I worked somewhere that had inherited about 800,000 lines of code, with 5 very sharp guys, and no one understood the code even remotely close to the original authors after 2 years of supporting it.</p><p>Companies need to understand that unless they pair program, when they lose the programmer, and he didn't have a partner, they lose the code. You might as well just rewrite it because it will take a new person as long to understand the old stuff, longer perhaps because he is not learning it in the orderly progression that was there when it was written.</p><p>There's a maxim, "He whose work is the most incomprehensible gets the most respect". The suits and pin heads who run software companies fall for this 100\% so the worst programmers, who by luck of the draw got to write the first spaghetti mess, are glorified while the maintenance programmers are seen as little more than janitors.</p><p>I make it a rule to go on unemployment before accepting a job as a maintenance programmer. Avoid it at almost any cost! It's a thankless job that usually ends in frustration and tears unless you have a VERY understanding manager or circumstances have granted you a very successful product that needs few fixes or enhancements.</p><p>Often companies hire programmers when they are behind or they lose people because they overworked them. Thus you are coming into a bad situation, already behind with everyone expecting miracles.</p></htmltext>
<tokenext>My advice to you is to start drinking heavily.A lot of good advice above , but there 's a political aspect to this which is very important.How you do will very much depend on the expectations that management has .
They very often assume maintaining code is much easier than writing it in the first place which is of course the exact opposite of the reality .
Make sure you talk with them about expectations up front , about how soon they expect you to be competent in the code.In all honesty , I worked somewhere that had inherited about 800,000 lines of code , with 5 very sharp guys , and no one understood the code even remotely close to the original authors after 2 years of supporting it.Companies need to understand that unless they pair program , when they lose the programmer , and he did n't have a partner , they lose the code .
You might as well just rewrite it because it will take a new person as long to understand the old stuff , longer perhaps because he is not learning it in the orderly progression that was there when it was written.There 's a maxim , " He whose work is the most incomprehensible gets the most respect " .
The suits and pin heads who run software companies fall for this 100 \ % so the worst programmers , who by luck of the draw got to write the first spaghetti mess , are glorified while the maintenance programmers are seen as little more than janitors.I make it a rule to go on unemployment before accepting a job as a maintenance programmer .
Avoid it at almost any cost !
It 's a thankless job that usually ends in frustration and tears unless you have a VERY understanding manager or circumstances have granted you a very successful product that needs few fixes or enhancements.Often companies hire programmers when they are behind or they lose people because they overworked them .
Thus you are coming into a bad situation , already behind with everyone expecting miracles .</tokentext>
<sentencetext>My advice to you is to start drinking heavily.A lot of good advice above, but there's a political aspect to this which is very important.How you do will very much depend on the expectations that management has.
They very often assume maintaining code is much easier than writing it in the first place which is of course the exact opposite of the reality.
Make sure you talk with them about expectations up front, about how soon they expect you to be competent in the code.In all honesty, I worked somewhere that had inherited about 800,000 lines of code, with 5 very sharp guys, and no one understood the code even remotely close to the original authors after 2 years of supporting it.Companies need to understand that unless they pair program, when they lose the programmer, and he didn't have a partner, they lose the code.
You might as well just rewrite it because it will take a new person as long to understand the old stuff, longer perhaps because he is not learning it in the orderly progression that was there when it was written.There's a maxim, "He whose work is the most incomprehensible gets the most respect".
The suits and pin heads who run software companies fall for this 100\% so the worst programmers, who by luck of the draw got to write the first spaghetti mess, are glorified while the maintenance programmers are seen as little more than janitors.I make it a rule to go on unemployment before accepting a job as a maintenance programmer.
Avoid it at almost any cost!
It's a thankless job that usually ends in frustration and tears unless you have a VERY understanding manager or circumstances have granted you a very successful product that needs few fixes or enhancements.Often companies hire programmers when they are behind or they lose people because they overworked them.
Thus you are coming into a bad situation, already behind with everyone expecting miracles.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123466</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123638</id>
	<title>Overtime Hours</title>
	<author>Anonymous</author>
	<datestamp>1265989260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I get this exact situation occasionally. The only possible answer is time. The longer you work with it the more clear it becomes. You may even end up liking their style.</p><p>If you can work a lot of overtime at the beginning that will help. That is exactly what I do but then again I have the free time and don't have kids to watch after and such.</p><p>Bite the fekken bullet if you can and put in a few 60 hour weeks.</p></htmltext>
<tokenext>I get this exact situation occasionally .
The only possible answer is time .
The longer you work with it the more clear it becomes .
You may even end up liking their style.If you can work a lot of overtime at the beginning that will help .
That is exactly what I do but then again I have the free time and do n't have kids to watch after and such.Bite the fekken bullet if you can and put in a few 60 hour weeks .</tokentext>
<sentencetext>I get this exact situation occasionally.
The only possible answer is time.
The longer you work with it the more clear it becomes.
You may even end up liking their style.If you can work a lot of overtime at the beginning that will help.
That is exactly what I do but then again I have the free time and don't have kids to watch after and such.Bite the fekken bullet if you can and put in a few 60 hour weeks.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122414</id>
	<title>Unit tests first</title>
	<author>Fenris Ulf</author>
	<datestamp>1265981220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Get a copy of Working Effectively With Legacy Code.  It'll help you get tests around the code base that give you the confidence to be able to change it without breaking anything.</p></htmltext>
<tokenext>Get a copy of Working Effectively With Legacy Code .
It 'll help you get tests around the code base that give you the confidence to be able to change it without breaking anything .</tokentext>
<sentencetext>Get a copy of Working Effectively With Legacy Code.
It'll help you get tests around the code base that give you the confidence to be able to change it without breaking anything.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123430</id>
	<title>30-40ksloc can be big!</title>
	<author>CodeMasterBob</author>
	<datestamp>1265987400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I've maintained code in the 30-40Kloc range that was "large" and really sucked to understand.  Fix one bug, create two new ones.  I maintain one such code base still, most modules have a McCabe Cyclomatic Complexity of over 100.  Can't refactor/rewrite/redesign, management won't approve it.  The original authors are long gone.
I embed lots of debug in the code and turn on the debug output on sections that I'm working on.</htmltext>
<tokenext>I 've maintained code in the 30-40Kloc range that was " large " and really sucked to understand .
Fix one bug , create two new ones .
I maintain one such code base still , most modules have a McCabe Cyclomatic Complexity of over 100 .
Ca n't refactor/rewrite/redesign , management wo n't approve it .
The original authors are long gone .
I embed lots of debug in the code and turn on the debug output on sections that I 'm working on .</tokentext>
<sentencetext>I've maintained code in the 30-40Kloc range that was "large" and really sucked to understand.
Fix one bug, create two new ones.
I maintain one such code base still, most modules have a McCabe Cyclomatic Complexity of over 100.
Can't refactor/rewrite/redesign, management won't approve it.
The original authors are long gone.
I embed lots of debug in the code and turn on the debug output on sections that I'm working on.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124248</id>
	<title>Re:Use it</title>
	<author>scotch</author>
	<datestamp>1265995140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Example:  in C-like languages that support pre- and post-increment, I expect the code to use only one or the other consistently, and never mix it with another expression.
</p><p>

Use one or the other consistently? But they don't mean the same thing.</p></div></div>
	</htmltext>
<tokenext>Example : in C-like languages that support pre- and post-increment , I expect the code to use only one or the other consistently , and never mix it with another expression .
Use one or the other consistently ?
But they do n't mean the same thing .</tokentext>
<sentencetext>Example:  in C-like languages that support pre- and post-increment, I expect the code to use only one or the other consistently, and never mix it with another expression.
Use one or the other consistently?
But they don't mean the same thing.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123616</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125068</id>
	<title>That's nothing useless answer</title>
	<author>Anonymous</author>
	<datestamp>1266091560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>That's  nothing. I work with 50K+ loc projects and because of that I won't offer any real solution to your problem. I just want you and everybody else to know it an so I write it here.</p></htmltext>
<tokenext>That 's nothing .
I work with 50K + loc projects and because of that I wo n't offer any real solution to your problem .
I just want you and everybody else to know it an so I write it here .</tokentext>
<sentencetext>That's  nothing.
I work with 50K+ loc projects and because of that I won't offer any real solution to your problem.
I just want you and everybody else to know it an so I write it here.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31135910</id>
	<title>Re:Tried and True</title>
	<author>Anonymous</author>
	<datestamp>1266177120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You obviously have no clue. At. All.</p></htmltext>
<tokenext>You obviously have no clue .
At. All .</tokentext>
<sentencetext>You obviously have no clue.
At. All.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122438</id>
	<title>You lucky bastard</title>
	<author>Anonymous</author>
	<datestamp>1265981340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>30k-40k...  I am working on a project with ~2 million lines of code spread across C#, SQL &amp; HTML/Javascript/CSS.  Mind you, there are 8 developers working on it, but each one of us has to pretty much know the entire thing.</p></htmltext>
<tokenext>30k-40k... I am working on a project with ~ 2 million lines of code spread across C # , SQL &amp; HTML/Javascript/CSS .
Mind you , there are 8 developers working on it , but each one of us has to pretty much know the entire thing .</tokentext>
<sentencetext>30k-40k...  I am working on a project with ~2 million lines of code spread across C#, SQL &amp; HTML/Javascript/CSS.
Mind you, there are 8 developers working on it, but each one of us has to pretty much know the entire thing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122902</id>
	<title>Don't be discouraged, just keep at it</title>
	<author>rxan</author>
	<datestamp>1265983680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Don't be discouraged. It's not like English where everyone writes in a familiar way. Everyone writes code a little differently and it is hard to go through it. Even with good commenting it can be difficult. Just persist and hope that you can contact one of the original authors.</htmltext>
<tokenext>Do n't be discouraged .
It 's not like English where everyone writes in a familiar way .
Everyone writes code a little differently and it is hard to go through it .
Even with good commenting it can be difficult .
Just persist and hope that you can contact one of the original authors .</tokentext>
<sentencetext>Don't be discouraged.
It's not like English where everyone writes in a familiar way.
Everyone writes code a little differently and it is hard to go through it.
Even with good commenting it can be difficult.
Just persist and hope that you can contact one of the original authors.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123794</id>
	<title>Correct the problem</title>
	<author>carlzum</author>
	<datestamp>1265990760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Add comments as you review and work with the code. The exercise will help you learn and provide documentation when maintaining or rewriting it. After you're familiar with the code you won't have the perspective of someone new to it, start now.</htmltext>
<tokenext>Add comments as you review and work with the code .
The exercise will help you learn and provide documentation when maintaining or rewriting it .
After you 're familiar with the code you wo n't have the perspective of someone new to it , start now .</tokentext>
<sentencetext>Add comments as you review and work with the code.
The exercise will help you learn and provide documentation when maintaining or rewriting it.
After you're familiar with the code you won't have the perspective of someone new to it, start now.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123300</id>
	<title>Re:Tried and True</title>
	<author>rocker\_wannabe</author>
	<datestamp>1265986440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p> <b>For you construction folks...</b> <br>
The time and money it takes to add another outlet to that wall will end up being larger than just starting over with a new house....<br><nobr> <wbr></nobr>....Ahhhhh, maybe NOT!</p><p>Rewriting something that cost tens or hundreds of thousands of dollars because it's hard to maintain would look wasteful and ridiculous to anyone that didn't work with software but it happens all the time.  This is what made me realize that programming is still an immature field.  I keep a copy of Edsger Dykstra's (or Dijkstra) <a href="http://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1036.PDF" title="utexas.edu">lecture</a> [utexas.edu] to University of Texas computer science students in 1988 on my desktop and read it every time I feel the urge to work for a software company again.  His premise is that if you teach people how to write code before you teach them the discrete math and logic framework that applies to programming you cripple them.  By not giving them the tools to write formal specifications that anyone with training could read and comprehend fairly quickly, you end with the industry situation we have now. The next programmer will either get a textual description of the functionality that is incomplete and not detailed enough or just get a copy of the source code.  Since the code mixes WHAT is supposed to be done with HOW it is supposed to be done it can be incredibly difficult to follow.</p><p>This means that the poor smuck that has to maintain someone else's code has to spend a huge amount of time reading and/or stepping through the code to try and understand how it works before any actual "code maintenance" can start.  It's ALWAYS possible to reverse engineer code and start drawing diagrams or commenting the code to help understand how it works.  Unfortunately, many programmers think they can do better and push hard for a refactoring of the code.  This is usually pure folly since the pressure to get something working will be even greater because there is already code available that mostly works so the odds of the next iteration getting any better is incredibly low unless the current code is TRULY a pile of excrement.</p><p>Since I've never been in a position to force a company to use formal methods for writing software specifications, and none of them thought they needed it, I've grown weary of watching new programmers thinking they are smarter than the people before them and choose to rewrite code. This usually ends badly.  As a System Test engineer for a number of years who has written "black box" and "white box" tests, I can say without a doubt that you can't create quality code through testing, especially in a commercial environment.  All you can do is cause the release date to slip until the really awful and obvious bugs are fixed.</p></htmltext>
<tokenext>For you construction folks.. . The time and money it takes to add another outlet to that wall will end up being larger than just starting over with a new house.... ....Ahhhhh , maybe NOT ! Rewriting something that cost tens or hundreds of thousands of dollars because it 's hard to maintain would look wasteful and ridiculous to anyone that did n't work with software but it happens all the time .
This is what made me realize that programming is still an immature field .
I keep a copy of Edsger Dykstra 's ( or Dijkstra ) lecture [ utexas.edu ] to University of Texas computer science students in 1988 on my desktop and read it every time I feel the urge to work for a software company again .
His premise is that if you teach people how to write code before you teach them the discrete math and logic framework that applies to programming you cripple them .
By not giving them the tools to write formal specifications that anyone with training could read and comprehend fairly quickly , you end with the industry situation we have now .
The next programmer will either get a textual description of the functionality that is incomplete and not detailed enough or just get a copy of the source code .
Since the code mixes WHAT is supposed to be done with HOW it is supposed to be done it can be incredibly difficult to follow.This means that the poor smuck that has to maintain someone else 's code has to spend a huge amount of time reading and/or stepping through the code to try and understand how it works before any actual " code maintenance " can start .
It 's ALWAYS possible to reverse engineer code and start drawing diagrams or commenting the code to help understand how it works .
Unfortunately , many programmers think they can do better and push hard for a refactoring of the code .
This is usually pure folly since the pressure to get something working will be even greater because there is already code available that mostly works so the odds of the next iteration getting any better is incredibly low unless the current code is TRULY a pile of excrement.Since I 've never been in a position to force a company to use formal methods for writing software specifications , and none of them thought they needed it , I 've grown weary of watching new programmers thinking they are smarter than the people before them and choose to rewrite code .
This usually ends badly .
As a System Test engineer for a number of years who has written " black box " and " white box " tests , I can say without a doubt that you ca n't create quality code through testing , especially in a commercial environment .
All you can do is cause the release date to slip until the really awful and obvious bugs are fixed .</tokentext>
<sentencetext> For you construction folks... 
The time and money it takes to add another outlet to that wall will end up being larger than just starting over with a new house.... ....Ahhhhh, maybe NOT!Rewriting something that cost tens or hundreds of thousands of dollars because it's hard to maintain would look wasteful and ridiculous to anyone that didn't work with software but it happens all the time.
This is what made me realize that programming is still an immature field.
I keep a copy of Edsger Dykstra's (or Dijkstra) lecture [utexas.edu] to University of Texas computer science students in 1988 on my desktop and read it every time I feel the urge to work for a software company again.
His premise is that if you teach people how to write code before you teach them the discrete math and logic framework that applies to programming you cripple them.
By not giving them the tools to write formal specifications that anyone with training could read and comprehend fairly quickly, you end with the industry situation we have now.
The next programmer will either get a textual description of the functionality that is incomplete and not detailed enough or just get a copy of the source code.
Since the code mixes WHAT is supposed to be done with HOW it is supposed to be done it can be incredibly difficult to follow.This means that the poor smuck that has to maintain someone else's code has to spend a huge amount of time reading and/or stepping through the code to try and understand how it works before any actual "code maintenance" can start.
It's ALWAYS possible to reverse engineer code and start drawing diagrams or commenting the code to help understand how it works.
Unfortunately, many programmers think they can do better and push hard for a refactoring of the code.
This is usually pure folly since the pressure to get something working will be even greater because there is already code available that mostly works so the odds of the next iteration getting any better is incredibly low unless the current code is TRULY a pile of excrement.Since I've never been in a position to force a company to use formal methods for writing software specifications, and none of them thought they needed it, I've grown weary of watching new programmers thinking they are smarter than the people before them and choose to rewrite code.
This usually ends badly.
As a System Test engineer for a number of years who has written "black box" and "white box" tests, I can say without a doubt that you can't create quality code through testing, especially in a commercial environment.
All you can do is cause the release date to slip until the really awful and obvious bugs are fixed.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123408</id>
	<title>Static analysis tools</title>
	<author>Anonymous</author>
	<datestamp>1265987160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Using a static analysis tool like findbugs - and fixing all the problems it fings is a great way to get to know all sorts of corners of a big codebase.</p><p>(and incidentally increase quality).</p></htmltext>
<tokenext>Using a static analysis tool like findbugs - and fixing all the problems it fings is a great way to get to know all sorts of corners of a big codebase .
( and incidentally increase quality ) .</tokentext>
<sentencetext>Using a static analysis tool like findbugs - and fixing all the problems it fings is a great way to get to know all sorts of corners of a big codebase.
(and incidentally increase quality).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31129438</id>
	<title>CXT C Exploration Tools</title>
	<author>northerner</author>
	<datestamp>1266052380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>When learning someone else's code, I have found Juergen Mueller's C Exploration Tools to be very useful.<p>
The CFT utility  (C Function Tree Generator) provides a summary of the functions and calling hierarchy.</p><p> The CST utility (C Structure Tree Generator) gives a summary of the data structures and how they are nested.</p><p>

I don't think these utilities have been updated for quite a while.
Can anyone suggest more modern versions of tools that do similar code analysis and reporting?</p></htmltext>
<tokenext>When learning someone else 's code , I have found Juergen Mueller 's C Exploration Tools to be very useful .
The CFT utility ( C Function Tree Generator ) provides a summary of the functions and calling hierarchy .
The CST utility ( C Structure Tree Generator ) gives a summary of the data structures and how they are nested .
I do n't think these utilities have been updated for quite a while .
Can anyone suggest more modern versions of tools that do similar code analysis and reporting ?</tokentext>
<sentencetext>When learning someone else's code, I have found Juergen Mueller's C Exploration Tools to be very useful.
The CFT utility  (C Function Tree Generator) provides a summary of the functions and calling hierarchy.
The CST utility (C Structure Tree Generator) gives a summary of the data structures and how they are nested.
I don't think these utilities have been updated for quite a while.
Can anyone suggest more modern versions of tools that do similar code analysis and reporting?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126612</id>
	<title>Re:Trace sessions and time</title>
	<author>radtea</author>
	<datestamp>1266073380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Set up an execution environment with debugger</p></div><p>I once worked with a fairly large legacy system that had been ported to Solaris from its original development system, which was a PDP-11 running RT-11/TSX, which as those of us who learned on it knew, had and addressing limit of 64k code and 64 k data in a single "overlay".  TSX was a multi-tasking layer on top of RT-11, which meant that one way to get around this limit was to run multiple processes and have them communicate via pipes, and this fundamental architecture had been maintained in the port.</p><p>This meant the most trivial path of execution involved multiple fork/execs and what amounted to asynchronous processing via message passing.  It was kind of elegant, in its own twisted way, but it meant that by far the easiest way of coming to grips with it was to put printf's everywhere (it was written in C) and have every program generate time-stamped output into its own file, then run a script to interleave the output so I could see a synchronous picture of what was going on.</p><p>After that I could attached gdb to various spawned processes and dig into them in a bit more detail, but that was a hopelessly laborious procedure for getting the overview, and because the pipe code was blind (the pipe endpoints were reused for whatever pipe happened to be open at the moment) it was almost impossible at any point to know what process you were talking to at a given point unless you'd seen it created:  there was essentially no way that any amount of static analysis could have revealed the underlying structure.</p><p>The company wanted me to change the code to add functionality that would have required touching virtually every file, and I was eventually able to show via various software engineering metrics that doing so would take approximately three years, mostly due to bug fixes (the cyclomatic complexity of some of the routines was into the hundreds, even not accounting for the bizarre architecture.)  They killed the project and we wrote something simpler and cleaner to do the same job from scratch.  That's rarely the best solution, but keep it in mind if things get too out of hand.</p></div>
	</htmltext>
<tokenext>Set up an execution environment with debuggerI once worked with a fairly large legacy system that had been ported to Solaris from its original development system , which was a PDP-11 running RT-11/TSX , which as those of us who learned on it knew , had and addressing limit of 64k code and 64 k data in a single " overlay " .
TSX was a multi-tasking layer on top of RT-11 , which meant that one way to get around this limit was to run multiple processes and have them communicate via pipes , and this fundamental architecture had been maintained in the port.This meant the most trivial path of execution involved multiple fork/execs and what amounted to asynchronous processing via message passing .
It was kind of elegant , in its own twisted way , but it meant that by far the easiest way of coming to grips with it was to put printf 's everywhere ( it was written in C ) and have every program generate time-stamped output into its own file , then run a script to interleave the output so I could see a synchronous picture of what was going on.After that I could attached gdb to various spawned processes and dig into them in a bit more detail , but that was a hopelessly laborious procedure for getting the overview , and because the pipe code was blind ( the pipe endpoints were reused for whatever pipe happened to be open at the moment ) it was almost impossible at any point to know what process you were talking to at a given point unless you 'd seen it created : there was essentially no way that any amount of static analysis could have revealed the underlying structure.The company wanted me to change the code to add functionality that would have required touching virtually every file , and I was eventually able to show via various software engineering metrics that doing so would take approximately three years , mostly due to bug fixes ( the cyclomatic complexity of some of the routines was into the hundreds , even not accounting for the bizarre architecture .
) They killed the project and we wrote something simpler and cleaner to do the same job from scratch .
That 's rarely the best solution , but keep it in mind if things get too out of hand .</tokentext>
<sentencetext>Set up an execution environment with debuggerI once worked with a fairly large legacy system that had been ported to Solaris from its original development system, which was a PDP-11 running RT-11/TSX, which as those of us who learned on it knew, had and addressing limit of 64k code and 64 k data in a single "overlay".
TSX was a multi-tasking layer on top of RT-11, which meant that one way to get around this limit was to run multiple processes and have them communicate via pipes, and this fundamental architecture had been maintained in the port.This meant the most trivial path of execution involved multiple fork/execs and what amounted to asynchronous processing via message passing.
It was kind of elegant, in its own twisted way, but it meant that by far the easiest way of coming to grips with it was to put printf's everywhere (it was written in C) and have every program generate time-stamped output into its own file, then run a script to interleave the output so I could see a synchronous picture of what was going on.After that I could attached gdb to various spawned processes and dig into them in a bit more detail, but that was a hopelessly laborious procedure for getting the overview, and because the pipe code was blind (the pipe endpoints were reused for whatever pipe happened to be open at the moment) it was almost impossible at any point to know what process you were talking to at a given point unless you'd seen it created:  there was essentially no way that any amount of static analysis could have revealed the underlying structure.The company wanted me to change the code to add functionality that would have required touching virtually every file, and I was eventually able to show via various software engineering metrics that doing so would take approximately three years, mostly due to bug fixes (the cyclomatic complexity of some of the routines was into the hundreds, even not accounting for the bizarre architecture.
)  They killed the project and we wrote something simpler and cleaner to do the same job from scratch.
That's rarely the best solution, but keep it in mind if things get too out of hand.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122354</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125234</id>
	<title>Re:Not lots of code</title>
	<author>Logic and Reason</author>
	<datestamp>1266094500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It's large when all 30-40k lines are in a single Perl file, with gobs of cut-n-paste code, dozens of global variables referenced from everywhere with no special naming convention, functions sometimes thousands of lines long, helpful function names like "p7e\_2b\_show", and only incredibly obvious comments like "#print output". Oh, and almost every one of about a thousand database statements, many of which involve user input, uses string interpolation instead of bound variables. No test suite or design documentation, either, so in many cases you have to guess at what the code is even supposed to be doing in the first place.<br>
<br>
Just hypothetically speaking, of course...</htmltext>
<tokenext>It 's large when all 30-40k lines are in a single Perl file , with gobs of cut-n-paste code , dozens of global variables referenced from everywhere with no special naming convention , functions sometimes thousands of lines long , helpful function names like " p7e \ _2b \ _show " , and only incredibly obvious comments like " # print output " .
Oh , and almost every one of about a thousand database statements , many of which involve user input , uses string interpolation instead of bound variables .
No test suite or design documentation , either , so in many cases you have to guess at what the code is even supposed to be doing in the first place .
Just hypothetically speaking , of course.. .</tokentext>
<sentencetext>It's large when all 30-40k lines are in a single Perl file, with gobs of cut-n-paste code, dozens of global variables referenced from everywhere with no special naming convention, functions sometimes thousands of lines long, helpful function names like "p7e\_2b\_show", and only incredibly obvious comments like "#print output".
Oh, and almost every one of about a thousand database statements, many of which involve user input, uses string interpolation instead of bound variables.
No test suite or design documentation, either, so in many cases you have to guess at what the code is even supposed to be doing in the first place.
Just hypothetically speaking, of course...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124084</id>
	<title>You *should* feel bad...</title>
	<author>Bright Apollo</author>
	<datestamp>1265993340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>... because clearly, you like setting the bar impossibly high for yourself.</p><p>You will never know the code as well as the original developer. so stop trying.  For very old cases &gt;10 years, that developer was also the analyst who gathered the requirements, further cementing you to a 3rd-bit player in the drama.  Let it go.</p><p>You *can* maintain someone else's code, though, if you can do a few things:<br>
&nbsp; &nbsp; &nbsp; -dispense with ego<br>
&nbsp; &nbsp; &nbsp; -learn to *read* code, especially as a reviewer<br>
&nbsp; &nbsp; &nbsp; -ask lots of questions</p><p>As a maintenance programmer, you have to be fearless about asking questions, even if they dead-end you.  You asked.  You were thrust into a bad spot, you do your best to figure out where you're at.  Assess the situation.  There's no rush to fix anything, it's not like the problem's going anywhere and no one is hiring clueless mission-critical coders.</p><p>Start small.  Start really small, like just reading the code as you might in a code review and see if you can spot trends.  If you've been doing this awhile, you can start picking up on the strengths and weaknesses of the author(s).  At the very least you can start to immerse yourself in the style and convention, making translation to the actual algorithms easier, i.e. what's this bit doing?  I'm not embarrassed to say I've professionally reviewed code that I could never write -- it was VB and ASP -- but I know what object-oriented code should look like, should be capable of doing, and this wasn't it.  It wasn't even good procedural/ iterative code... but that's besides the point.  The point is, I know when to use a while loop, a for loop, and when to unroll the loop.  It's the kind of knowledge that comes in handy no matter what language I'm looking at.  Declarative?  No problem, it's set-based thinking and straight Boolean logic.  Functional?  Fine, let's start busting down the parentheticals.  It's also about moving data into a register, eventually.</p><p>So, you start small, you read the code, you trace some data by hand, a little, and then... run the fuckin' thing with a debugger, step by step, and watch the data move.  If it takes you all day to run it once, you're entirely ready on day two to start messing with it.  You've likely done what only the original developer has ever done, and that's seen data at the top run straight through to the bottom.</p><p>--#</p></htmltext>
<tokenext>... because clearly , you like setting the bar impossibly high for yourself.You will never know the code as well as the original developer .
so stop trying .
For very old cases &gt; 10 years , that developer was also the analyst who gathered the requirements , further cementing you to a 3rd-bit player in the drama .
Let it go.You * can * maintain someone else 's code , though , if you can do a few things :       -dispense with ego       -learn to * read * code , especially as a reviewer       -ask lots of questionsAs a maintenance programmer , you have to be fearless about asking questions , even if they dead-end you .
You asked .
You were thrust into a bad spot , you do your best to figure out where you 're at .
Assess the situation .
There 's no rush to fix anything , it 's not like the problem 's going anywhere and no one is hiring clueless mission-critical coders.Start small .
Start really small , like just reading the code as you might in a code review and see if you can spot trends .
If you 've been doing this awhile , you can start picking up on the strengths and weaknesses of the author ( s ) .
At the very least you can start to immerse yourself in the style and convention , making translation to the actual algorithms easier , i.e .
what 's this bit doing ?
I 'm not embarrassed to say I 've professionally reviewed code that I could never write -- it was VB and ASP -- but I know what object-oriented code should look like , should be capable of doing , and this was n't it .
It was n't even good procedural/ iterative code... but that 's besides the point .
The point is , I know when to use a while loop , a for loop , and when to unroll the loop .
It 's the kind of knowledge that comes in handy no matter what language I 'm looking at .
Declarative ? No problem , it 's set-based thinking and straight Boolean logic .
Functional ? Fine , let 's start busting down the parentheticals .
It 's also about moving data into a register , eventually.So , you start small , you read the code , you trace some data by hand , a little , and then... run the fuckin ' thing with a debugger , step by step , and watch the data move .
If it takes you all day to run it once , you 're entirely ready on day two to start messing with it .
You 've likely done what only the original developer has ever done , and that 's seen data at the top run straight through to the bottom.-- #</tokentext>
<sentencetext>... because clearly, you like setting the bar impossibly high for yourself.You will never know the code as well as the original developer.
so stop trying.
For very old cases &gt;10 years, that developer was also the analyst who gathered the requirements, further cementing you to a 3rd-bit player in the drama.
Let it go.You *can* maintain someone else's code, though, if you can do a few things:
      -dispense with ego
      -learn to *read* code, especially as a reviewer
      -ask lots of questionsAs a maintenance programmer, you have to be fearless about asking questions, even if they dead-end you.
You asked.
You were thrust into a bad spot, you do your best to figure out where you're at.
Assess the situation.
There's no rush to fix anything, it's not like the problem's going anywhere and no one is hiring clueless mission-critical coders.Start small.
Start really small, like just reading the code as you might in a code review and see if you can spot trends.
If you've been doing this awhile, you can start picking up on the strengths and weaknesses of the author(s).
At the very least you can start to immerse yourself in the style and convention, making translation to the actual algorithms easier, i.e.
what's this bit doing?
I'm not embarrassed to say I've professionally reviewed code that I could never write -- it was VB and ASP -- but I know what object-oriented code should look like, should be capable of doing, and this wasn't it.
It wasn't even good procedural/ iterative code... but that's besides the point.
The point is, I know when to use a while loop, a for loop, and when to unroll the loop.
It's the kind of knowledge that comes in handy no matter what language I'm looking at.
Declarative?  No problem, it's set-based thinking and straight Boolean logic.
Functional?  Fine, let's start busting down the parentheticals.
It's also about moving data into a register, eventually.So, you start small, you read the code, you trace some data by hand, a little, and then... run the fuckin' thing with a debugger, step by step, and watch the data move.
If it takes you all day to run it once, you're entirely ready on day two to start messing with it.
You've likely done what only the original developer has ever done, and that's seen data at the top run straight through to the bottom.--#</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123380</id>
	<title>Step 1: Find a very large wall</title>
	<author>Deffexor</author>
	<datestamp>1265986980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Step 2: Print out all the code (in very small font) and paste the code up on the wall<br>Step 3: Identify all the classes, functions, DBs, etc.<br>Step 4: Create a visual map (on a white board) of how they're all linked together.<br>Step 5: PROFIT!</p><p>That wasn't so hard, now, was it?<nobr> <wbr></nobr>:)</p></htmltext>
<tokenext>Step 2 : Print out all the code ( in very small font ) and paste the code up on the wallStep 3 : Identify all the classes , functions , DBs , etc.Step 4 : Create a visual map ( on a white board ) of how they 're all linked together.Step 5 : PROFIT ! That was n't so hard , now , was it ?
: )</tokentext>
<sentencetext>Step 2: Print out all the code (in very small font) and paste the code up on the wallStep 3: Identify all the classes, functions, DBs, etc.Step 4: Create a visual map (on a white board) of how they're all linked together.Step 5: PROFIT!That wasn't so hard, now, was it?
:)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125478</id>
	<title>Hu?</title>
	<author>angel'o'sphere</author>
	<datestamp>1266056760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>You've inherited a fairly large (30-40 thousand lines) collection of code<nobr> <wbr></nobr>... </i></p><p>30k to 40k lines of code is not large by any means of measurement.</p><p>A programmer running mad will chill that out in a year or less. But perhaps that is your problem<nobr> <wbr></nobr>...</p><p>Anyway as hint of understanding I suggest debugging it. Perhaps you find old bug reports (hopefully fixed meanwhile) and you can try to play them back with a debugger and put nice break points and get an idea. OTOH I fear your program is just old plain C so it might be hard to grasp in debug mode nevertheless.</p><p>Good luck.</p><p>angel'o'sphere</p></htmltext>
<tokenext>You 've inherited a fairly large ( 30-40 thousand lines ) collection of code ... 30k to 40k lines of code is not large by any means of measurement.A programmer running mad will chill that out in a year or less .
But perhaps that is your problem ...Anyway as hint of understanding I suggest debugging it .
Perhaps you find old bug reports ( hopefully fixed meanwhile ) and you can try to play them back with a debugger and put nice break points and get an idea .
OTOH I fear your program is just old plain C so it might be hard to grasp in debug mode nevertheless.Good luck.angel'o'sphere</tokentext>
<sentencetext>You've inherited a fairly large (30-40 thousand lines) collection of code ... 30k to 40k lines of code is not large by any means of measurement.A programmer running mad will chill that out in a year or less.
But perhaps that is your problem ...Anyway as hint of understanding I suggest debugging it.
Perhaps you find old bug reports (hopefully fixed meanwhile) and you can try to play them back with a debugger and put nice break points and get an idea.
OTOH I fear your program is just old plain C so it might be hard to grasp in debug mode nevertheless.Good luck.angel'o'sphere</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125946</id>
	<title>Think about it</title>
	<author>Sla$hPot</author>
	<datestamp>1266064440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You need to</p><p>1. Understand the business rules.<br>You need to know what the system / application does before you can begin making changes to the code.</p><p>2. Get an overview of the system design / code structure. If there is any (otherwise it is going to be very difficult).<br>Break down the system into use cases and try to see what part of the code each case covers.<br>That should give you an idea of the business logic and the class structures (assuming it is not one big bowl of spaghetti).</p><p>3. Create a working document with your diagrams and development plans.<br>Put all your observations on a whiteboard, paper or a napkin as needed. But remember to draw it Visio, Word or OpenOffice.Writer too.<br>You don't have to do this all at once. It can be done as you move into the code to fix bugs or when making changes.</p><p>It will probably take you between 6 to 18 months to get fully acquainted with 30-40K lines of code.<br>It also depends on how hard business is pushing you. The more pressure on bug fixing and system changes, the less time you will have to learn about the system as a whole.<br>Even though 30-40K lines isn't that much it is probably more than a one man job.<br>If it is a business critical system. It is more likely to be a 2-3 headcount.<br>You should have you own exit strategy ready and get out of there, in case business wont take your challenges seriously.</p><p>Anyways i hope they pay you well.<br>Good luck with it.</p></htmltext>
<tokenext>You need to1 .
Understand the business rules.You need to know what the system / application does before you can begin making changes to the code.2 .
Get an overview of the system design / code structure .
If there is any ( otherwise it is going to be very difficult ) .Break down the system into use cases and try to see what part of the code each case covers.That should give you an idea of the business logic and the class structures ( assuming it is not one big bowl of spaghetti ) .3 .
Create a working document with your diagrams and development plans.Put all your observations on a whiteboard , paper or a napkin as needed .
But remember to draw it Visio , Word or OpenOffice.Writer too.You do n't have to do this all at once .
It can be done as you move into the code to fix bugs or when making changes.It will probably take you between 6 to 18 months to get fully acquainted with 30-40K lines of code.It also depends on how hard business is pushing you .
The more pressure on bug fixing and system changes , the less time you will have to learn about the system as a whole.Even though 30-40K lines is n't that much it is probably more than a one man job.If it is a business critical system .
It is more likely to be a 2-3 headcount.You should have you own exit strategy ready and get out of there , in case business wont take your challenges seriously.Anyways i hope they pay you well.Good luck with it .</tokentext>
<sentencetext>You need to1.
Understand the business rules.You need to know what the system / application does before you can begin making changes to the code.2.
Get an overview of the system design / code structure.
If there is any (otherwise it is going to be very difficult).Break down the system into use cases and try to see what part of the code each case covers.That should give you an idea of the business logic and the class structures (assuming it is not one big bowl of spaghetti).3.
Create a working document with your diagrams and development plans.Put all your observations on a whiteboard, paper or a napkin as needed.
But remember to draw it Visio, Word or OpenOffice.Writer too.You don't have to do this all at once.
It can be done as you move into the code to fix bugs or when making changes.It will probably take you between 6 to 18 months to get fully acquainted with 30-40K lines of code.It also depends on how hard business is pushing you.
The more pressure on bug fixing and system changes, the less time you will have to learn about the system as a whole.Even though 30-40K lines isn't that much it is probably more than a one man job.If it is a business critical system.
It is more likely to be a 2-3 headcount.You should have you own exit strategy ready and get out of there, in case business wont take your challenges seriously.Anyways i hope they pay you well.Good luck with it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124106</id>
	<title>Call Stacks</title>
	<author>SuperKendall</author>
	<datestamp>1265993640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I find the most instructive way is to see a real call stack from an application.</p><p>When I was doing Java a great tool was TogetherJ - you could point it at a method and say, show me all the possible calls this method can make.  This can yield a really huge visual document (that I printed out on a plotter) but it was really useful into peering into the application.</p><p>If you don't have a tool like that, the next best thing is picking some interesting things way down in the bowels of the application, and get a call stack at that point (either breakpoint while you are running or some kind of log).  Do that in a few places, and you start to have a sense of how things flow.</p><p>The thing I like to understand in any application, my own or others, is data flow - knowing how calls reach either other can help you understand better how data flows through the system.</p></htmltext>
<tokenext>I find the most instructive way is to see a real call stack from an application.When I was doing Java a great tool was TogetherJ - you could point it at a method and say , show me all the possible calls this method can make .
This can yield a really huge visual document ( that I printed out on a plotter ) but it was really useful into peering into the application.If you do n't have a tool like that , the next best thing is picking some interesting things way down in the bowels of the application , and get a call stack at that point ( either breakpoint while you are running or some kind of log ) .
Do that in a few places , and you start to have a sense of how things flow.The thing I like to understand in any application , my own or others , is data flow - knowing how calls reach either other can help you understand better how data flows through the system .</tokentext>
<sentencetext>I find the most instructive way is to see a real call stack from an application.When I was doing Java a great tool was TogetherJ - you could point it at a method and say, show me all the possible calls this method can make.
This can yield a really huge visual document (that I printed out on a plotter) but it was really useful into peering into the application.If you don't have a tool like that, the next best thing is picking some interesting things way down in the bowels of the application, and get a call stack at that point (either breakpoint while you are running or some kind of log).
Do that in a few places, and you start to have a sense of how things flow.The thing I like to understand in any application, my own or others, is data flow - knowing how calls reach either other can help you understand better how data flows through the system.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125074</id>
	<title>Re:As a maintenance programmer</title>
	<author>Anonymous</author>
	<datestamp>1266091740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>On my current job I was handed an extremely poorly written bunch of programs (spanning various languages, neither of which the original coder mastered very well.) The code was written by someone who had apparently left the company in anger, and not all of it was even at an operational stage. Being much more of a 'creator' personality than a 'maintainer' personality, I ended up rewriting half of it from scratch and discarding the other half. Luckily that was what the company wanted me to do.</p><p>I can agree with every point on your list though. Just making a clean copy of the source, running git init &amp;&amp; git add . will do wonders to your productivity, because you know you're free to tinker and dissect and mess around as much as you want. If you want to truly pull something apart. I'd also add: Take good notes! Digging through old code is much like an archaeological expedition. And it's amazing how fast you'll forget something if you haven't written it down.</p></htmltext>
<tokenext>On my current job I was handed an extremely poorly written bunch of programs ( spanning various languages , neither of which the original coder mastered very well .
) The code was written by someone who had apparently left the company in anger , and not all of it was even at an operational stage .
Being much more of a 'creator ' personality than a 'maintainer ' personality , I ended up rewriting half of it from scratch and discarding the other half .
Luckily that was what the company wanted me to do.I can agree with every point on your list though .
Just making a clean copy of the source , running git init &amp;&amp; git add .
will do wonders to your productivity , because you know you 're free to tinker and dissect and mess around as much as you want .
If you want to truly pull something apart .
I 'd also add : Take good notes !
Digging through old code is much like an archaeological expedition .
And it 's amazing how fast you 'll forget something if you have n't written it down .</tokentext>
<sentencetext>On my current job I was handed an extremely poorly written bunch of programs (spanning various languages, neither of which the original coder mastered very well.
) The code was written by someone who had apparently left the company in anger, and not all of it was even at an operational stage.
Being much more of a 'creator' personality than a 'maintainer' personality, I ended up rewriting half of it from scratch and discarding the other half.
Luckily that was what the company wanted me to do.I can agree with every point on your list though.
Just making a clean copy of the source, running git init &amp;&amp; git add .
will do wonders to your productivity, because you know you're free to tinker and dissect and mess around as much as you want.
If you want to truly pull something apart.
I'd also add: Take good notes!
Digging through old code is much like an archaeological expedition.
And it's amazing how fast you'll forget something if you haven't written it down.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124330</id>
	<title>Another possible pitfall</title>
	<author>laughingcoyote</author>
	<datestamp>1265995860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I've been in a similar situation myself, though thankfully not (as sounds possible for you) by myself, and I learned one thing above anything else.</p><p>Never, ever, trust your memory. As soon as you figure something out, write it down. Right that second, while it's still fresh in your mind exactly what you learned. It doesn't matter as much how you write it down (commenting the code, a separate text document, or for that matter keeping a notebook and pencil close to hand), just that you do. If you don't, you will run across the sinking feeling that you already figured this problem out before, and since you don't remember what the answer was, you're about to do it again. It will also help others that you work with, and even if you don't right now, it's quite possible that you will.</p></htmltext>
<tokenext>I 've been in a similar situation myself , though thankfully not ( as sounds possible for you ) by myself , and I learned one thing above anything else.Never , ever , trust your memory .
As soon as you figure something out , write it down .
Right that second , while it 's still fresh in your mind exactly what you learned .
It does n't matter as much how you write it down ( commenting the code , a separate text document , or for that matter keeping a notebook and pencil close to hand ) , just that you do .
If you do n't , you will run across the sinking feeling that you already figured this problem out before , and since you do n't remember what the answer was , you 're about to do it again .
It will also help others that you work with , and even if you do n't right now , it 's quite possible that you will .</tokentext>
<sentencetext>I've been in a similar situation myself, though thankfully not (as sounds possible for you) by myself, and I learned one thing above anything else.Never, ever, trust your memory.
As soon as you figure something out, write it down.
Right that second, while it's still fresh in your mind exactly what you learned.
It doesn't matter as much how you write it down (commenting the code, a separate text document, or for that matter keeping a notebook and pencil close to hand), just that you do.
If you don't, you will run across the sinking feeling that you already figured this problem out before, and since you don't remember what the answer was, you're about to do it again.
It will also help others that you work with, and even if you don't right now, it's quite possible that you will.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126370</id>
	<title>Re:Use it</title>
	<author>moonbender</author>
	<datestamp>1266070860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I don't know about other debugging GUIs, but Eclipse can easily evaluate an expression without crutches like the immediate window or watches. Mark the expression and press Ctrl-D for a toString or Ctrl-I for an inspection window of the evaluation result. I assume most other modern IDEs can do this.</p></htmltext>
<tokenext>I do n't know about other debugging GUIs , but Eclipse can easily evaluate an expression without crutches like the immediate window or watches .
Mark the expression and press Ctrl-D for a toString or Ctrl-I for an inspection window of the evaluation result .
I assume most other modern IDEs can do this .</tokentext>
<sentencetext>I don't know about other debugging GUIs, but Eclipse can easily evaluate an expression without crutches like the immediate window or watches.
Mark the expression and press Ctrl-D for a toString or Ctrl-I for an inspection window of the evaluation result.
I assume most other modern IDEs can do this.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122710</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31139088</id>
	<title>It just takes time</title>
	<author>wesw02</author>
	<datestamp>1266155820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I don't really have a good answer to the problem. I just graduated college 4 months ago, got hired to work on a code base that is around a million lines of code and it's not easy. If your lucky the code maintains a certain amount of consistence and you find a lot of similarity in various objects/modules. I found that spending some one on one time with my debugger (gdb) has really helped me to get a handle on the structure (request/response socket classes, model/view controllers, cache dbs, etc). Patience is your best tool.</htmltext>
<tokenext>I do n't really have a good answer to the problem .
I just graduated college 4 months ago , got hired to work on a code base that is around a million lines of code and it 's not easy .
If your lucky the code maintains a certain amount of consistence and you find a lot of similarity in various objects/modules .
I found that spending some one on one time with my debugger ( gdb ) has really helped me to get a handle on the structure ( request/response socket classes , model/view controllers , cache dbs , etc ) .
Patience is your best tool .</tokentext>
<sentencetext>I don't really have a good answer to the problem.
I just graduated college 4 months ago, got hired to work on a code base that is around a million lines of code and it's not easy.
If your lucky the code maintains a certain amount of consistence and you find a lot of similarity in various objects/modules.
I found that spending some one on one time with my debugger (gdb) has really helped me to get a handle on the structure (request/response socket classes, model/view controllers, cache dbs, etc).
Patience is your best tool.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124354</id>
	<title>Re:As a maintenance programmer</title>
	<author>Anonymous</author>
	<datestamp>1265996160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The unit tests are vital, but as someone who recently inherited approximately the same size code base from an outsourced project I found refactoring to be THE most useful thing. Once you start rewriting small sections of code you will understand what the classes (or modules / procedures if it's not OO) do. It took me a month to completely test, document, and refactor my code base, but I took the project from about 35k to roughly 20k LOC.</p><p>When you do start to refactor (notice I said 'when', not 'if') this book is invaluable: http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672</p></htmltext>
<tokenext>The unit tests are vital , but as someone who recently inherited approximately the same size code base from an outsourced project I found refactoring to be THE most useful thing .
Once you start rewriting small sections of code you will understand what the classes ( or modules / procedures if it 's not OO ) do .
It took me a month to completely test , document , and refactor my code base , but I took the project from about 35k to roughly 20k LOC.When you do start to refactor ( notice I said 'when ' , not 'if ' ) this book is invaluable : http : //www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672</tokentext>
<sentencetext>The unit tests are vital, but as someone who recently inherited approximately the same size code base from an outsourced project I found refactoring to be THE most useful thing.
Once you start rewriting small sections of code you will understand what the classes (or modules / procedures if it's not OO) do.
It took me a month to completely test, document, and refactor my code base, but I took the project from about 35k to roughly 20k LOC.When you do start to refactor (notice I said 'when', not 'if') this book is invaluable: http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123082</id>
	<title>Unit Test Suites</title>
	<author>shanmoon</author>
	<datestamp>1265984940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>
I inherited a product with a code base of a few hundred thousands lines of code when I was a fairly new software engineer. To make it worse, it was cross platform (AIX/Windows/Linkux/HUX) with something like 20 nested make files.

The code was essentially a business service application. My solution was to talk to the consumers of the product and learn what each service call was supposed to do. I then wrote a set of test suites for the application. I had to continually update the suite as a I went along, but it definitely exposed unexpected couplings or other strange behaviors in the code. I also ended up converted the project over to an ant based build script (ant was brand new at the time).

It defintely taught me what the code was doing and how it was doing.</htmltext>
<tokenext>I inherited a product with a code base of a few hundred thousands lines of code when I was a fairly new software engineer .
To make it worse , it was cross platform ( AIX/Windows/Linkux/HUX ) with something like 20 nested make files .
The code was essentially a business service application .
My solution was to talk to the consumers of the product and learn what each service call was supposed to do .
I then wrote a set of test suites for the application .
I had to continually update the suite as a I went along , but it definitely exposed unexpected couplings or other strange behaviors in the code .
I also ended up converted the project over to an ant based build script ( ant was brand new at the time ) .
It defintely taught me what the code was doing and how it was doing .</tokentext>
<sentencetext>
I inherited a product with a code base of a few hundred thousands lines of code when I was a fairly new software engineer.
To make it worse, it was cross platform (AIX/Windows/Linkux/HUX) with something like 20 nested make files.
The code was essentially a business service application.
My solution was to talk to the consumers of the product and learn what each service call was supposed to do.
I then wrote a set of test suites for the application.
I had to continually update the suite as a I went along, but it definitely exposed unexpected couplings or other strange behaviors in the code.
I also ended up converted the project over to an ant based build script (ant was brand new at the time).
It defintely taught me what the code was doing and how it was doing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122782</id>
	<title>Re:Use it</title>
	<author>Anonymous</author>
	<datestamp>1265982960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I'm not trying to troll here but how do you write anything without variables?

Or are you suggesting that some people will use too many variables like:
$FirstName
$MiddleName
$LastName
$BirthDate
$Gender
when they could have simplified their code with a single class called Person?</htmltext>
<tokenext>I 'm not trying to troll here but how do you write anything without variables ?
Or are you suggesting that some people will use too many variables like : $ FirstName $ MiddleName $ LastName $ BirthDate $ Gender when they could have simplified their code with a single class called Person ?</tokentext>
<sentencetext>I'm not trying to troll here but how do you write anything without variables?
Or are you suggesting that some people will use too many variables like:
$FirstName
$MiddleName
$LastName
$BirthDate
$Gender
when they could have simplified their code with a single class called Person?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125026</id>
	<title>Pay attention to quality.</title>
	<author>seebs</author>
	<datestamp>1266004380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Look for things like misspellings, undefined behavior, indentation screwups, and so on.</p><p>The reason is, if there's a lot of these, that's a big clue to you that you have to be MUCH more careful with the code, because it is probably crap.  Stupid comments?  Probably crap.  Explanations of things that are a bit surprising, with citations or justification?  Maybe not so bad.  Comments that are visibly out of sync with the code?  Bad.  Consistent naming convention?  Good.  Inconsistent naming convention?  Bad.  Tons of copy and paste?  Bad.</p><p>Knowing whether code is good or bad does you a ton of good in understanding it.  If you know the code is crap, you have a better chance of guessing how some idiot will have gotten it wrong.  If you know the code is good, you can often guess how someone would have tried to make it robust and/or maintainable.</p></htmltext>
<tokenext>Look for things like misspellings , undefined behavior , indentation screwups , and so on.The reason is , if there 's a lot of these , that 's a big clue to you that you have to be MUCH more careful with the code , because it is probably crap .
Stupid comments ?
Probably crap .
Explanations of things that are a bit surprising , with citations or justification ?
Maybe not so bad .
Comments that are visibly out of sync with the code ?
Bad. Consistent naming convention ?
Good. Inconsistent naming convention ?
Bad. Tons of copy and paste ?
Bad.Knowing whether code is good or bad does you a ton of good in understanding it .
If you know the code is crap , you have a better chance of guessing how some idiot will have gotten it wrong .
If you know the code is good , you can often guess how someone would have tried to make it robust and/or maintainable .</tokentext>
<sentencetext>Look for things like misspellings, undefined behavior, indentation screwups, and so on.The reason is, if there's a lot of these, that's a big clue to you that you have to be MUCH more careful with the code, because it is probably crap.
Stupid comments?
Probably crap.
Explanations of things that are a bit surprising, with citations or justification?
Maybe not so bad.
Comments that are visibly out of sync with the code?
Bad.  Consistent naming convention?
Good.  Inconsistent naming convention?
Bad.  Tons of copy and paste?
Bad.Knowing whether code is good or bad does you a ton of good in understanding it.
If you know the code is crap, you have a better chance of guessing how some idiot will have gotten it wrong.
If you know the code is good, you can often guess how someone would have tried to make it robust and/or maintainable.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124270</id>
	<title>Read, read, read</title>
	<author>Anonymous</author>
	<datestamp>1265995320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>To understand the code, you need to read the code.  You'll also need to index the code so you can bounce around it to read, since the limit of most people's stack is only a few items.</p><p>Next, figure out the dead wood.  Don't remove it yet.</p><p>Next, learn what the heck the thing is supposed to do.  Find out from what the code interfaces to what it is supposed to do.  Talk to users and/or the business owners.  talk to the authors of the code.  Speak to the problem domain experts.</p><p>Next, make sure that you know when it works.  Regression tests are your friend here.  You need both global tests to make sure you didn't break anything in the large, as well as unit tests, to make sure you didn't break anything in the small.</p><p>Next, start to remove the deadwood to make sure it conforms to the spec.  This can be an excellent way to learn how the code works, but also is fraught with danger.  Why is that extra field always '0'?  Remove it.  Could  be nobody notices, or it is critical for the parser for the consumer of the data to continue working.  Learn what matters and why.  This step may not be feasible in some environments.</p><p>Assume everything will take 3x what you think it will.  There's often hidden dependencies, no matter how clueful the original author was.  Odds are he/she/it wasn't clueful (playing the numbers), which means 3x is too optimistic.</p><p>Resist the urge to recast it in your own image.  It won't help as much as you think it will.  Rewriting from scratch often is a waste of time, even if it thinks it is a good idea at the time.  I've been burned by this several times, often with only so-so results.</p><p>Plan on spending extra time documenting and speculating what the code should be like.  Chances are this won't be the only time you have to do this.</p><p>I've also found it useful in learning to read code to read, say, the 4.3 BSD network code then read the annotated books on the topic.  It is big enough to be interesting, and small enough to keep in your head.  The linux kernel books cover something that's really too big to learn from easily.</p><p>Nobody teaches this anymore, but that's another rant.</p></htmltext>
<tokenext>To understand the code , you need to read the code .
You 'll also need to index the code so you can bounce around it to read , since the limit of most people 's stack is only a few items.Next , figure out the dead wood .
Do n't remove it yet.Next , learn what the heck the thing is supposed to do .
Find out from what the code interfaces to what it is supposed to do .
Talk to users and/or the business owners .
talk to the authors of the code .
Speak to the problem domain experts.Next , make sure that you know when it works .
Regression tests are your friend here .
You need both global tests to make sure you did n't break anything in the large , as well as unit tests , to make sure you did n't break anything in the small.Next , start to remove the deadwood to make sure it conforms to the spec .
This can be an excellent way to learn how the code works , but also is fraught with danger .
Why is that extra field always '0 ' ?
Remove it .
Could be nobody notices , or it is critical for the parser for the consumer of the data to continue working .
Learn what matters and why .
This step may not be feasible in some environments.Assume everything will take 3x what you think it will .
There 's often hidden dependencies , no matter how clueful the original author was .
Odds are he/she/it was n't clueful ( playing the numbers ) , which means 3x is too optimistic.Resist the urge to recast it in your own image .
It wo n't help as much as you think it will .
Rewriting from scratch often is a waste of time , even if it thinks it is a good idea at the time .
I 've been burned by this several times , often with only so-so results.Plan on spending extra time documenting and speculating what the code should be like .
Chances are this wo n't be the only time you have to do this.I 've also found it useful in learning to read code to read , say , the 4.3 BSD network code then read the annotated books on the topic .
It is big enough to be interesting , and small enough to keep in your head .
The linux kernel books cover something that 's really too big to learn from easily.Nobody teaches this anymore , but that 's another rant .</tokentext>
<sentencetext>To understand the code, you need to read the code.
You'll also need to index the code so you can bounce around it to read, since the limit of most people's stack is only a few items.Next, figure out the dead wood.
Don't remove it yet.Next, learn what the heck the thing is supposed to do.
Find out from what the code interfaces to what it is supposed to do.
Talk to users and/or the business owners.
talk to the authors of the code.
Speak to the problem domain experts.Next, make sure that you know when it works.
Regression tests are your friend here.
You need both global tests to make sure you didn't break anything in the large, as well as unit tests, to make sure you didn't break anything in the small.Next, start to remove the deadwood to make sure it conforms to the spec.
This can be an excellent way to learn how the code works, but also is fraught with danger.
Why is that extra field always '0'?
Remove it.
Could  be nobody notices, or it is critical for the parser for the consumer of the data to continue working.
Learn what matters and why.
This step may not be feasible in some environments.Assume everything will take 3x what you think it will.
There's often hidden dependencies, no matter how clueful the original author was.
Odds are he/she/it wasn't clueful (playing the numbers), which means 3x is too optimistic.Resist the urge to recast it in your own image.
It won't help as much as you think it will.
Rewriting from scratch often is a waste of time, even if it thinks it is a good idea at the time.
I've been burned by this several times, often with only so-so results.Plan on spending extra time documenting and speculating what the code should be like.
Chances are this won't be the only time you have to do this.I've also found it useful in learning to read code to read, say, the 4.3 BSD network code then read the annotated books on the topic.
It is big enough to be interesting, and small enough to keep in your head.
The linux kernel books cover something that's really too big to learn from easily.Nobody teaches this anymore, but that's another rant.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122886</id>
	<title>Re:Not at all.</title>
	<author>Jane Q. Public</author>
	<datestamp>1265983680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>To add to that:
<br> <br>
What language is it in? That could make a big difference in our answers. But in general, if it is very old code it should at least contain comments. If it was written in the last few years, the code should be in discrete sections that are organized in a logical manner. If not, then they were either seriously old-school programmers, or hacks.</htmltext>
<tokenext>To add to that : What language is it in ?
That could make a big difference in our answers .
But in general , if it is very old code it should at least contain comments .
If it was written in the last few years , the code should be in discrete sections that are organized in a logical manner .
If not , then they were either seriously old-school programmers , or hacks .</tokentext>
<sentencetext>To add to that:
 
What language is it in?
That could make a big difference in our answers.
But in general, if it is very old code it should at least contain comments.
If it was written in the last few years, the code should be in discrete sections that are organized in a logical manner.
If not, then they were either seriously old-school programmers, or hacks.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122286</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125378</id>
	<title>Re:Tried and True</title>
	<author>Anonymous</author>
	<datestamp>1266054480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>There are times to rewrite and times not to rewrite, and the decision should rarely be made on code quality alone.  There are two factors other to consider.</p><p>The first is the time needed to reimplement.  The longer this time is, the higher your risk of cancellation.  Yes, I know, your manager promised you that they would stick it out until the bitter end.  But things change.  What usually happens is that there is some big emergency and the old code is resurrected "temporarily" to solve a specific customer issue.  These issues keep popping up over and over again until your are spending almost all your time in the old code.  Finally, they cancel the new project.  Alternatively, the company runs short on cash and moves back to its "core functionality", scrapping anything that isn't absolutely necessary.  If your rewrite takes longer than a month or two, I give you only a 10\% chance of completion.</p><p>The second factor is requirements gathering.  Do you have an organized description of all the functionality of the current program?  Are all the bug fixes and subsequent feature additions rectified with the main requirements documents so that the whole thing is up to date and complete?  Thought not.  In every case I have ever experienced the only place that accurately documents the current functionality of the program is the source code itself.  And if you can't understand it, then you probably are going to forget a huge number of small issues when you reimplement.  If you manage to get to the release date without cancellation, your project will almost certainly be a disaster when the customers decide they hate the new version.  Often, no matter how much better the new code is, management will decide to revert to the old code base.</p><p>There are two times when you should rewrite: if it won't take a long time (4-8 weeks tops) and/or the requirements of the project have changed dramatically to the point where everything has to be rethought anyway.  Other than that, in the vast majority of circumstances you will be better off putting the existing code under tests and refactoring as best as you can.</p></htmltext>
<tokenext>There are times to rewrite and times not to rewrite , and the decision should rarely be made on code quality alone .
There are two factors other to consider.The first is the time needed to reimplement .
The longer this time is , the higher your risk of cancellation .
Yes , I know , your manager promised you that they would stick it out until the bitter end .
But things change .
What usually happens is that there is some big emergency and the old code is resurrected " temporarily " to solve a specific customer issue .
These issues keep popping up over and over again until your are spending almost all your time in the old code .
Finally , they cancel the new project .
Alternatively , the company runs short on cash and moves back to its " core functionality " , scrapping anything that is n't absolutely necessary .
If your rewrite takes longer than a month or two , I give you only a 10 \ % chance of completion.The second factor is requirements gathering .
Do you have an organized description of all the functionality of the current program ?
Are all the bug fixes and subsequent feature additions rectified with the main requirements documents so that the whole thing is up to date and complete ?
Thought not .
In every case I have ever experienced the only place that accurately documents the current functionality of the program is the source code itself .
And if you ca n't understand it , then you probably are going to forget a huge number of small issues when you reimplement .
If you manage to get to the release date without cancellation , your project will almost certainly be a disaster when the customers decide they hate the new version .
Often , no matter how much better the new code is , management will decide to revert to the old code base.There are two times when you should rewrite : if it wo n't take a long time ( 4-8 weeks tops ) and/or the requirements of the project have changed dramatically to the point where everything has to be rethought anyway .
Other than that , in the vast majority of circumstances you will be better off putting the existing code under tests and refactoring as best as you can .</tokentext>
<sentencetext>There are times to rewrite and times not to rewrite, and the decision should rarely be made on code quality alone.
There are two factors other to consider.The first is the time needed to reimplement.
The longer this time is, the higher your risk of cancellation.
Yes, I know, your manager promised you that they would stick it out until the bitter end.
But things change.
What usually happens is that there is some big emergency and the old code is resurrected "temporarily" to solve a specific customer issue.
These issues keep popping up over and over again until your are spending almost all your time in the old code.
Finally, they cancel the new project.
Alternatively, the company runs short on cash and moves back to its "core functionality", scrapping anything that isn't absolutely necessary.
If your rewrite takes longer than a month or two, I give you only a 10\% chance of completion.The second factor is requirements gathering.
Do you have an organized description of all the functionality of the current program?
Are all the bug fixes and subsequent feature additions rectified with the main requirements documents so that the whole thing is up to date and complete?
Thought not.
In every case I have ever experienced the only place that accurately documents the current functionality of the program is the source code itself.
And if you can't understand it, then you probably are going to forget a huge number of small issues when you reimplement.
If you manage to get to the release date without cancellation, your project will almost certainly be a disaster when the customers decide they hate the new version.
Often, no matter how much better the new code is, management will decide to revert to the old code base.There are two times when you should rewrite: if it won't take a long time (4-8 weeks tops) and/or the requirements of the project have changed dramatically to the point where everything has to be rethought anyway.
Other than that, in the vast majority of circumstances you will be better off putting the existing code under tests and refactoring as best as you can.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123000</id>
	<title>Re:It depends on the language</title>
	<author>budgenator</author>
	<datestamp>1265984340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I was on fire once you insensitive clod.</p></htmltext>
<tokenext>I was on fire once you insensitive clod .</tokentext>
<sentencetext>I was on fire once you insensitive clod.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122256</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123038</id>
	<title>Become the developer.</title>
	<author>Anonymous</author>
	<datestamp>1265984580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>There are a couple of questions that you should ask yourself:</p><p>First I would find out out how the program was designed, that is: Is it a bottom-up or top-down? Some languages offer better facilities for writing programs in one style or the other and some problems are solved better in one style or the other. Try to think like somebody who was given the task of "implementing X."</p><p>If they chose bottom-up, the developers might have been competent enough to refactor code as they were writing it. How would somebody start implementing X from the bottom-up? Start deep down in the hierarchy of abstractions with the fundamental abstract data types that drive most of the program. If file timestamps are accurate, they should be able to tell you what the oldest module of the program is. Start there, then move on to the next layer that interfaces with that code. Wash, rinse, repeat.</p><p>If it's top-down, find the design documents. If they're unavailable, reverse engineer them from the current code base. Is it a clean design? Ask yourself if they were competent enough to come up with it right away. How many people were working at the time and what were their levels of proficiencies? Hope that the most proficient programmers were assigned the most difficult modules. At some point integration must have happened. Find the spots where it did. Those are module boundaries. Read each module's code progressing "along the boundaries."</p><p>The more accurate X was defined in the first place the later you're going to run into the uglies, the WTFs. That's going to be inevitable. Every code base has WTFs and OMGs.</p><p>Ultimately, you must read all code to understand all code. That shouldn't come as a surprise.</p><p>Chris Eineke</p></htmltext>
<tokenext>There are a couple of questions that you should ask yourself : First I would find out out how the program was designed , that is : Is it a bottom-up or top-down ?
Some languages offer better facilities for writing programs in one style or the other and some problems are solved better in one style or the other .
Try to think like somebody who was given the task of " implementing X .
" If they chose bottom-up , the developers might have been competent enough to refactor code as they were writing it .
How would somebody start implementing X from the bottom-up ?
Start deep down in the hierarchy of abstractions with the fundamental abstract data types that drive most of the program .
If file timestamps are accurate , they should be able to tell you what the oldest module of the program is .
Start there , then move on to the next layer that interfaces with that code .
Wash , rinse , repeat.If it 's top-down , find the design documents .
If they 're unavailable , reverse engineer them from the current code base .
Is it a clean design ?
Ask yourself if they were competent enough to come up with it right away .
How many people were working at the time and what were their levels of proficiencies ?
Hope that the most proficient programmers were assigned the most difficult modules .
At some point integration must have happened .
Find the spots where it did .
Those are module boundaries .
Read each module 's code progressing " along the boundaries .
" The more accurate X was defined in the first place the later you 're going to run into the uglies , the WTFs .
That 's going to be inevitable .
Every code base has WTFs and OMGs.Ultimately , you must read all code to understand all code .
That should n't come as a surprise.Chris Eineke</tokentext>
<sentencetext>There are a couple of questions that you should ask yourself:First I would find out out how the program was designed, that is: Is it a bottom-up or top-down?
Some languages offer better facilities for writing programs in one style or the other and some problems are solved better in one style or the other.
Try to think like somebody who was given the task of "implementing X.
"If they chose bottom-up, the developers might have been competent enough to refactor code as they were writing it.
How would somebody start implementing X from the bottom-up?
Start deep down in the hierarchy of abstractions with the fundamental abstract data types that drive most of the program.
If file timestamps are accurate, they should be able to tell you what the oldest module of the program is.
Start there, then move on to the next layer that interfaces with that code.
Wash, rinse, repeat.If it's top-down, find the design documents.
If they're unavailable, reverse engineer them from the current code base.
Is it a clean design?
Ask yourself if they were competent enough to come up with it right away.
How many people were working at the time and what were their levels of proficiencies?
Hope that the most proficient programmers were assigned the most difficult modules.
At some point integration must have happened.
Find the spots where it did.
Those are module boundaries.
Read each module's code progressing "along the boundaries.
"The more accurate X was defined in the first place the later you're going to run into the uglies, the WTFs.
That's going to be inevitable.
Every code base has WTFs and OMGs.Ultimately, you must read all code to understand all code.
That shouldn't come as a surprise.Chris Eineke</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122398</id>
	<title>Some things I do to figure out code...</title>
	<author>CFBMoo1</author>
	<datestamp>1265981100000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>PL/SQL or cobol or whatever they throw at me I poke, prod, and play with it in a test environment. Someone up above mentioned pencil and paper to draw out how everything relates and that is a very good practice I've found to just get to know things. It's not instant but it helps more then you initially think. Also I use Open Office Draw to map out things as well.<nobr> <wbr></nobr>:P</htmltext>
<tokenext>PL/SQL or cobol or whatever they throw at me I poke , prod , and play with it in a test environment .
Someone up above mentioned pencil and paper to draw out how everything relates and that is a very good practice I 've found to just get to know things .
It 's not instant but it helps more then you initially think .
Also I use Open Office Draw to map out things as well .
: P</tokentext>
<sentencetext>PL/SQL or cobol or whatever they throw at me I poke, prod, and play with it in a test environment.
Someone up above mentioned pencil and paper to draw out how everything relates and that is a very good practice I've found to just get to know things.
It's not instant but it helps more then you initially think.
Also I use Open Office Draw to map out things as well.
:P</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314</id>
	<title>Use it</title>
	<author>Anonymous</author>
	<datestamp>1265980740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The only way to learn the code is to work with it.  Simply reading through it won't help, you have to go try to change things and see what works and what doesn't.  </p><p>The main thing that bothers me when working with other peoples code is the sheer number of variables they use.  I tend not to declare a new variable unless it is absolutely necessary (and in object oriented programming variables other than pointers are almost never necessary).  It seems like code written this way is easier to read and understand (and significantly smaller).  This is slashdot, so there are a lot of other programmers out there.  Am I off base here?  What do you think about intermediate variables that are not strictly necessary?</p></htmltext>
<tokenext>The only way to learn the code is to work with it .
Simply reading through it wo n't help , you have to go try to change things and see what works and what does n't .
The main thing that bothers me when working with other peoples code is the sheer number of variables they use .
I tend not to declare a new variable unless it is absolutely necessary ( and in object oriented programming variables other than pointers are almost never necessary ) .
It seems like code written this way is easier to read and understand ( and significantly smaller ) .
This is slashdot , so there are a lot of other programmers out there .
Am I off base here ?
What do you think about intermediate variables that are not strictly necessary ?</tokentext>
<sentencetext>The only way to learn the code is to work with it.
Simply reading through it won't help, you have to go try to change things and see what works and what doesn't.
The main thing that bothers me when working with other peoples code is the sheer number of variables they use.
I tend not to declare a new variable unless it is absolutely necessary (and in object oriented programming variables other than pointers are almost never necessary).
It seems like code written this way is easier to read and understand (and significantly smaller).
This is slashdot, so there are a lot of other programmers out there.
Am I off base here?
What do you think about intermediate variables that are not strictly necessary?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124936</id>
	<title>To learn the code</title>
	<author>Anonymous</author>
	<datestamp>1266003120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>flow chart it.  Crawling through the code is the best way to learn it.</p></htmltext>
<tokenext>flow chart it .
Crawling through the code is the best way to learn it .</tokentext>
<sentencetext>flow chart it.
Crawling through the code is the best way to learn it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126580</id>
	<title>Re:Spaghetti Code</title>
	<author>azgard</author>
	<datestamp>1266073020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's interesting story, but you are lucky that the Big Boss wasn't the original author.</p></htmltext>
<tokenext>It 's interesting story , but you are lucky that the Big Boss was n't the original author .</tokentext>
<sentencetext>It's interesting story, but you are lucky that the Big Boss wasn't the original author.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123866</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125900</id>
	<title>Code Rocket</title>
	<author>Grimxn</author>
	<datestamp>1266063780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Check out <a href="http://www.rapidqualitysystems.com/root/Home/Products" title="rapidqualitysystems.com" rel="nofollow">Code Rocket</a> [rapidqualitysystems.com] - this is what it's for.</htmltext>
<tokenext>Check out Code Rocket [ rapidqualitysystems.com ] - this is what it 's for .</tokentext>
<sentencetext>Check out Code Rocket [rapidqualitysystems.com] - this is what it's for.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123280</id>
	<title>Fix some bugs in the defect tracking database</title>
	<author>mstockmyer</author>
	<datestamp>1265986320000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>When I joined a group that had a 2 Million SLOC program, I learned the most by fixing defects. It gave me a good reason to go traipsing through the codebase. It's painful, but it gives you purpose while reading the code. Just plain reading it gets boring.</htmltext>
<tokenext>When I joined a group that had a 2 Million SLOC program , I learned the most by fixing defects .
It gave me a good reason to go traipsing through the codebase .
It 's painful , but it gives you purpose while reading the code .
Just plain reading it gets boring .</tokentext>
<sentencetext>When I joined a group that had a 2 Million SLOC program, I learned the most by fixing defects.
It gave me a good reason to go traipsing through the codebase.
It's painful, but it gives you purpose while reading the code.
Just plain reading it gets boring.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125880</id>
	<title>Re:Use it</title>
	<author>pooly7</author>
	<datestamp>1266063480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>The only way to learn the code is to work with it.</p> </div><p>If you're new to a team, best thing you can do to learn a new codebase, is to reply to loads of support questions coming around, you'll have to dig in to understand how it works and reply to the questions. Same when there is a bug, try to find it, then work out a solution and ask your co-woker what he thinks about it.
Also, a good test to see if you know your codebase is getting a call from your boss and be able to fix the bug over the phone when he explains it to you.</p></div>
	</htmltext>
<tokenext>The only way to learn the code is to work with it .
If you 're new to a team , best thing you can do to learn a new codebase , is to reply to loads of support questions coming around , you 'll have to dig in to understand how it works and reply to the questions .
Same when there is a bug , try to find it , then work out a solution and ask your co-woker what he thinks about it .
Also , a good test to see if you know your codebase is getting a call from your boss and be able to fix the bug over the phone when he explains it to you .</tokentext>
<sentencetext>The only way to learn the code is to work with it.
If you're new to a team, best thing you can do to learn a new codebase, is to reply to loads of support questions coming around, you'll have to dig in to understand how it works and reply to the questions.
Same when there is a bug, try to find it, then work out a solution and ask your co-woker what he thinks about it.
Also, a good test to see if you know your codebase is getting a call from your boss and be able to fix the bug over the phone when he explains it to you.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125316</id>
	<title>Learn the use cases</title>
	<author>lena\_10326</author>
	<datestamp>1266053040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think the biggest trouble is with knowing why things were done. You will look at the code and see that decisions appear to have been made arbitrarily. You'll scratch your head wondering "they had 3 design options but they chose this one, why?". You need to understand the use cases to know the why. It's not always obvious because many times its based on tribal knowledge that was obvious at the time but not now so no one thought to document it.</p><p>Ask around and find out of any of the higher ups from the original project still remain. Setup an interview with them to get the project history and go over the use cases. When you go back to the code, you'll better understand why things were done.</p></htmltext>
<tokenext>I think the biggest trouble is with knowing why things were done .
You will look at the code and see that decisions appear to have been made arbitrarily .
You 'll scratch your head wondering " they had 3 design options but they chose this one , why ? " .
You need to understand the use cases to know the why .
It 's not always obvious because many times its based on tribal knowledge that was obvious at the time but not now so no one thought to document it.Ask around and find out of any of the higher ups from the original project still remain .
Setup an interview with them to get the project history and go over the use cases .
When you go back to the code , you 'll better understand why things were done .</tokentext>
<sentencetext>I think the biggest trouble is with knowing why things were done.
You will look at the code and see that decisions appear to have been made arbitrarily.
You'll scratch your head wondering "they had 3 design options but they chose this one, why?".
You need to understand the use cases to know the why.
It's not always obvious because many times its based on tribal knowledge that was obvious at the time but not now so no one thought to document it.Ask around and find out of any of the higher ups from the original project still remain.
Setup an interview with them to get the project history and go over the use cases.
When you go back to the code, you'll better understand why things were done.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31159924</id>
	<title>That's easy</title>
	<author>Anonymous</author>
	<datestamp>1266313620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>1 - Convince your customer that the platform the project is based on is deprecated, and they need a complete rewrite in a fancy completely new technology, so they can have all the functionality previous programmers denied them, and more. For example, you could migrate from Cobol to Java, from Java to C#, from C# to Go...<br>2 - Be sure to do it with fancy shiny graphics, so the customer can see there are advantages to the new stinky pile of crap with half of the previous functionality you have sell to them for a lot of money.<br>3 - When they complain about bugs and lack of functionality, sell them a mainteinance contract. They will sign it, or lose all the huge pile of money they have already wasted in the rewrite.<br>4 - Profit!</p></htmltext>
<tokenext>1 - Convince your customer that the platform the project is based on is deprecated , and they need a complete rewrite in a fancy completely new technology , so they can have all the functionality previous programmers denied them , and more .
For example , you could migrate from Cobol to Java , from Java to C # , from C # to Go...2 - Be sure to do it with fancy shiny graphics , so the customer can see there are advantages to the new stinky pile of crap with half of the previous functionality you have sell to them for a lot of money.3 - When they complain about bugs and lack of functionality , sell them a mainteinance contract .
They will sign it , or lose all the huge pile of money they have already wasted in the rewrite.4 - Profit !</tokentext>
<sentencetext>1 - Convince your customer that the platform the project is based on is deprecated, and they need a complete rewrite in a fancy completely new technology, so they can have all the functionality previous programmers denied them, and more.
For example, you could migrate from Cobol to Java, from Java to C#, from C# to Go...2 - Be sure to do it with fancy shiny graphics, so the customer can see there are advantages to the new stinky pile of crap with half of the previous functionality you have sell to them for a lot of money.3 - When they complain about bugs and lack of functionality, sell them a mainteinance contract.
They will sign it, or lose all the huge pile of money they have already wasted in the rewrite.4 - Profit!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124536</id>
	<title>Re:Use it</title>
	<author>Anonymous</author>
	<datestamp>1265998440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I try to follow the "max one page per method" rule. Following that rule you cannot define many variables anyway.</p></htmltext>
<tokenext>I try to follow the " max one page per method " rule .
Following that rule you can not define many variables anyway .</tokentext>
<sentencetext>I try to follow the "max one page per method" rule.
Following that rule you cannot define many variables anyway.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124614</id>
	<title>Re:My Dick is Bigger than Your 250,000 lines of co</title>
	<author>Mean Variance</author>
	<datestamp>1265999280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>5) Plan to remove the dead weight. There's always a lot of dead weight in these near-abandoned projects. Get an idea how to simplify things and plan your work in phases.</p></div><p>There's a lot of anti-IDE rhetoric going on, but I rely heavily on mine, Eclipse (for Java programming). I also rely on Vim, TextPad, less, and so on depending on the task. But for this particular question and the point about dead weight, leverage your IDE to clean house. You can play with compiler and static analysis flags to remove things like unused: private methods, imports, variables or whatever is applicable to your language. If the formatting is inconsistent, run a formatter that pleases your eye (assuming there isn't a group standard for that<nobr> <wbr></nobr>... another religious programmer's topic).</p><p>Other parts of Eclipse that I rely on especially when I'm in another team's code (we have about 2m real LOCs):<br>* Call hierarchy [ctl-alt-H]<br>* References [ctl-shift-G]<br>* Class hierarchy [f4]</p><p>Where I am, some of these conveniences are becoming more difficult to leverage as Spring and its XML configurations define object relationships.</p></div>
	</htmltext>
<tokenext>5 ) Plan to remove the dead weight .
There 's always a lot of dead weight in these near-abandoned projects .
Get an idea how to simplify things and plan your work in phases.There 's a lot of anti-IDE rhetoric going on , but I rely heavily on mine , Eclipse ( for Java programming ) .
I also rely on Vim , TextPad , less , and so on depending on the task .
But for this particular question and the point about dead weight , leverage your IDE to clean house .
You can play with compiler and static analysis flags to remove things like unused : private methods , imports , variables or whatever is applicable to your language .
If the formatting is inconsistent , run a formatter that pleases your eye ( assuming there is n't a group standard for that ... another religious programmer 's topic ) .Other parts of Eclipse that I rely on especially when I 'm in another team 's code ( we have about 2m real LOCs ) : * Call hierarchy [ ctl-alt-H ] * References [ ctl-shift-G ] * Class hierarchy [ f4 ] Where I am , some of these conveniences are becoming more difficult to leverage as Spring and its XML configurations define object relationships .</tokentext>
<sentencetext>5) Plan to remove the dead weight.
There's always a lot of dead weight in these near-abandoned projects.
Get an idea how to simplify things and plan your work in phases.There's a lot of anti-IDE rhetoric going on, but I rely heavily on mine, Eclipse (for Java programming).
I also rely on Vim, TextPad, less, and so on depending on the task.
But for this particular question and the point about dead weight, leverage your IDE to clean house.
You can play with compiler and static analysis flags to remove things like unused: private methods, imports, variables or whatever is applicable to your language.
If the formatting is inconsistent, run a formatter that pleases your eye (assuming there isn't a group standard for that ... another religious programmer's topic).Other parts of Eclipse that I rely on especially when I'm in another team's code (we have about 2m real LOCs):* Call hierarchy [ctl-alt-H]* References [ctl-shift-G]* Class hierarchy [f4]Where I am, some of these conveniences are becoming more difficult to leverage as Spring and its XML configurations define object relationships.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123466</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125302</id>
	<title>codebase I never did understand...</title>
	<author>Anonymous</author>
	<datestamp>1266052680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Have to share painful past tale.  I inherited a ~30K line app that ran on an embedded system of which we had two copies of the hardware, both in production.  These were used to do PIN block translations from an acquirer network to the bank/verifier networks &amp; associated security stuff using strange-o NCR security processing equipment plugged into some kind of Intel OEM chassis with an 80186 board running the embedded app, talking to a mainframe over a pair of 48Kbps SDLC links (and the SDLC protocol was part of the app) powered by the i82530 SCC.</p><p>I inherited the code because the author, who was a friend of mine, went home with the flu one day and dropped dead 3 days later -- aged 29.</p><p>Worst part...I couldn't even rebuild the current binary that was in production from the code I found on his PC.  But I spent time trying to understand the code base...and it was hard, especially without being able to run it on anything.</p><p>I had a manager who simply wouldn't listen to me until I had printed all the code out -- which was pointless, and I was too stubborn to just print the code out and say...ok, that was a waste of time, now what.</p><p>A middle manager was appointed who came in bursting with enthusiasm.  She *did* print out all the code...um, using MS Word as an editor so that it "looked nice" (i.e., appropriately<br>girly girly choice of fonts).</p><p>She was very keen and said...I'm sure we can go through this in a morning.  Well, I was secretly thrilled when she was on the verge of tears by teatime. We never got on top of that system -- our management woudn't consider my suggestion that we redo the thing on a normal PC &amp; use Linux and change the comms stuff to TCP/IP.  But one of the other disgruntled people from the company saw the gap, quit, started his own consultancy &amp; after not too long, showed me the same SP stuff that was remotely managable over X11.</p></htmltext>
<tokenext>Have to share painful past tale .
I inherited a ~ 30K line app that ran on an embedded system of which we had two copies of the hardware , both in production .
These were used to do PIN block translations from an acquirer network to the bank/verifier networks &amp; associated security stuff using strange-o NCR security processing equipment plugged into some kind of Intel OEM chassis with an 80186 board running the embedded app , talking to a mainframe over a pair of 48Kbps SDLC links ( and the SDLC protocol was part of the app ) powered by the i82530 SCC.I inherited the code because the author , who was a friend of mine , went home with the flu one day and dropped dead 3 days later -- aged 29.Worst part...I could n't even rebuild the current binary that was in production from the code I found on his PC .
But I spent time trying to understand the code base...and it was hard , especially without being able to run it on anything.I had a manager who simply would n't listen to me until I had printed all the code out -- which was pointless , and I was too stubborn to just print the code out and say...ok , that was a waste of time , now what.A middle manager was appointed who came in bursting with enthusiasm .
She * did * print out all the code...um , using MS Word as an editor so that it " looked nice " ( i.e. , appropriatelygirly girly choice of fonts ) .She was very keen and said...I 'm sure we can go through this in a morning .
Well , I was secretly thrilled when she was on the verge of tears by teatime .
We never got on top of that system -- our management woud n't consider my suggestion that we redo the thing on a normal PC &amp; use Linux and change the comms stuff to TCP/IP .
But one of the other disgruntled people from the company saw the gap , quit , started his own consultancy &amp; after not too long , showed me the same SP stuff that was remotely managable over X11 .</tokentext>
<sentencetext>Have to share painful past tale.
I inherited a ~30K line app that ran on an embedded system of which we had two copies of the hardware, both in production.
These were used to do PIN block translations from an acquirer network to the bank/verifier networks &amp; associated security stuff using strange-o NCR security processing equipment plugged into some kind of Intel OEM chassis with an 80186 board running the embedded app, talking to a mainframe over a pair of 48Kbps SDLC links (and the SDLC protocol was part of the app) powered by the i82530 SCC.I inherited the code because the author, who was a friend of mine, went home with the flu one day and dropped dead 3 days later -- aged 29.Worst part...I couldn't even rebuild the current binary that was in production from the code I found on his PC.
But I spent time trying to understand the code base...and it was hard, especially without being able to run it on anything.I had a manager who simply wouldn't listen to me until I had printed all the code out -- which was pointless, and I was too stubborn to just print the code out and say...ok, that was a waste of time, now what.A middle manager was appointed who came in bursting with enthusiasm.
She *did* print out all the code...um, using MS Word as an editor so that it "looked nice" (i.e., appropriatelygirly girly choice of fonts).She was very keen and said...I'm sure we can go through this in a morning.
Well, I was secretly thrilled when she was on the verge of tears by teatime.
We never got on top of that system -- our management woudn't consider my suggestion that we redo the thing on a normal PC &amp; use Linux and change the comms stuff to TCP/IP.
But one of the other disgruntled people from the company saw the gap, quit, started his own consultancy &amp; after not too long, showed me the same SP stuff that was remotely managable over X11.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126770</id>
	<title>I just completed something similar...</title>
	<author>mswhippingboy</author>
	<datestamp>1266075000000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>I inherited a 15+ year old application about two years ago of similar size written in C (actually Pro*C) that had a long history of crashes (invalid pointers), memory leaks and incorrect results. I was tasked to add additional functionality to the application. I was able to implement the additional functionality, but because of the requirements of the project, I did not address all the structural defects in the application.
<p> As a result, although the new functionality worked fine, the application still suffered for the "spaghetti" code of patches upon patches of years of various developers adding additional capabilities, but no one ever addressed the reliability of the application. The support group for this application was clearly frustrated with years of late night calls and hours and hours spent trying to correct errors.
</p><p>
About 6 months ago I was tasked with essentially "cloning" the application for new business purposes. I proposed porting the application to a newer, more modern language (java). It took a lot of selling (i.e. convincing management and other developers that the end result would run just as fast, be easier to maintain and have more reliability), but I was able to get them to buy off on it.
</p><p>The rewrite was completed about 3 months ago and the results were better than i had hoped for. I was able to complete the rewrite in the same amount of time allocated for the original "enhancement" project. The application actually runs faster than the old one, has yet to crash (it runs 24x7), and the code is well structured and easy to maintain. We're now in the position that if/when another "enhancement" is requested to the old application, we can simply clone the new java version and completely replace the old app. Given the results of the last project, it won't be a hard sell (especially to the support group) to go the java route.
</p><p>I know this is a long post, but the bottom line is that sometimes (more often than many realize), recoding an old application in a modern language and bringing it into the 21st century rather than patching old code can pay off dividends beyond the basic added functionality.</p></htmltext>
<tokenext>I inherited a 15 + year old application about two years ago of similar size written in C ( actually Pro * C ) that had a long history of crashes ( invalid pointers ) , memory leaks and incorrect results .
I was tasked to add additional functionality to the application .
I was able to implement the additional functionality , but because of the requirements of the project , I did not address all the structural defects in the application .
As a result , although the new functionality worked fine , the application still suffered for the " spaghetti " code of patches upon patches of years of various developers adding additional capabilities , but no one ever addressed the reliability of the application .
The support group for this application was clearly frustrated with years of late night calls and hours and hours spent trying to correct errors .
About 6 months ago I was tasked with essentially " cloning " the application for new business purposes .
I proposed porting the application to a newer , more modern language ( java ) .
It took a lot of selling ( i.e .
convincing management and other developers that the end result would run just as fast , be easier to maintain and have more reliability ) , but I was able to get them to buy off on it .
The rewrite was completed about 3 months ago and the results were better than i had hoped for .
I was able to complete the rewrite in the same amount of time allocated for the original " enhancement " project .
The application actually runs faster than the old one , has yet to crash ( it runs 24x7 ) , and the code is well structured and easy to maintain .
We 're now in the position that if/when another " enhancement " is requested to the old application , we can simply clone the new java version and completely replace the old app .
Given the results of the last project , it wo n't be a hard sell ( especially to the support group ) to go the java route .
I know this is a long post , but the bottom line is that sometimes ( more often than many realize ) , recoding an old application in a modern language and bringing it into the 21st century rather than patching old code can pay off dividends beyond the basic added functionality .</tokentext>
<sentencetext>I inherited a 15+ year old application about two years ago of similar size written in C (actually Pro*C) that had a long history of crashes (invalid pointers), memory leaks and incorrect results.
I was tasked to add additional functionality to the application.
I was able to implement the additional functionality, but because of the requirements of the project, I did not address all the structural defects in the application.
As a result, although the new functionality worked fine, the application still suffered for the "spaghetti" code of patches upon patches of years of various developers adding additional capabilities, but no one ever addressed the reliability of the application.
The support group for this application was clearly frustrated with years of late night calls and hours and hours spent trying to correct errors.
About 6 months ago I was tasked with essentially "cloning" the application for new business purposes.
I proposed porting the application to a newer, more modern language (java).
It took a lot of selling (i.e.
convincing management and other developers that the end result would run just as fast, be easier to maintain and have more reliability), but I was able to get them to buy off on it.
The rewrite was completed about 3 months ago and the results were better than i had hoped for.
I was able to complete the rewrite in the same amount of time allocated for the original "enhancement" project.
The application actually runs faster than the old one, has yet to crash (it runs 24x7), and the code is well structured and easy to maintain.
We're now in the position that if/when another "enhancement" is requested to the old application, we can simply clone the new java version and completely replace the old app.
Given the results of the last project, it won't be a hard sell (especially to the support group) to go the java route.
I know this is a long post, but the bottom line is that sometimes (more often than many realize), recoding an old application in a modern language and bringing it into the 21st century rather than patching old code can pay off dividends beyond the basic added functionality.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125290</id>
	<title>Re:Tried and True</title>
	<author>lena\_10326</author>
	<datestamp>1266052380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>So an individual is going to rewrite a production system composed of 30-40k lines of code all by themselves when the original team had a bigger budget, more teammates, more time, face to face access to clients, and participation in all the requirements gathering sessions?</p><p>Don't underestimate the effort that went into legacy systems. Unless your team resources on par with the original team or you have a magic productivity bullet (perhaps migrating from old school Fortran to Java), don't even try it. Go with a piecemeal series of revisions over time. It can be done (I've done it before) but you must prioritize and cull the list of worst offenders. It requires having solid understanding of the code base and a clear plan for the bits to rework and the bits to keep.</p></htmltext>
<tokenext>So an individual is going to rewrite a production system composed of 30-40k lines of code all by themselves when the original team had a bigger budget , more teammates , more time , face to face access to clients , and participation in all the requirements gathering sessions ? Do n't underestimate the effort that went into legacy systems .
Unless your team resources on par with the original team or you have a magic productivity bullet ( perhaps migrating from old school Fortran to Java ) , do n't even try it .
Go with a piecemeal series of revisions over time .
It can be done ( I 've done it before ) but you must prioritize and cull the list of worst offenders .
It requires having solid understanding of the code base and a clear plan for the bits to rework and the bits to keep .</tokentext>
<sentencetext>So an individual is going to rewrite a production system composed of 30-40k lines of code all by themselves when the original team had a bigger budget, more teammates, more time, face to face access to clients, and participation in all the requirements gathering sessions?Don't underestimate the effort that went into legacy systems.
Unless your team resources on par with the original team or you have a magic productivity bullet (perhaps migrating from old school Fortran to Java), don't even try it.
Go with a piecemeal series of revisions over time.
It can be done (I've done it before) but you must prioritize and cull the list of worst offenders.
It requires having solid understanding of the code base and a clear plan for the bits to rework and the bits to keep.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122410</id>
	<title>Little by Little does the trick</title>
	<author>cheesybagel</author>
	<datestamp>1265981220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>
Getting something that allows you to browse code more efficiently certainly helps. There are tools for doing that.
</p><p>
Another trick is to compile in debug mode, run the code inside a debugger, then break and watch the function call stack. This can help understand deeply nested code some more.
</p><p>
In the long run however nothing substitutes practice using the codebase. Even an author can get lost if he spends some years away from the code... Either you just do not remember anymore, or the code was changed so much by someone else's edits it gets hard to recognize. Or both.
</p><p>
If the code does not have consistent coding style standards run it thought a indenting program. You may lose the revision control history but you certainly get a more than reasonable return from it being easier to parse manually. If it does have a consistent coding style standard, even if it is something you are not used to, probably better to keep it that way.
</p><p>
Cleanup code by refactoring common code blocks out, or doing other code refactoring that reduces line code code and/or increases readability. Make sure the refactored version is functionally equivalent to the non-refactored version. Unless you are fixing a bug. Even if you are fixing a bug document the change just in case something actually relies on bug for bug compatibility.
</p><p>
If you do not have time to do cleanups just keep adding the functionality you need. Eventually you will have read enough code that you will know the codebase. If you do not need to add any more functionality, who cares anyway?</p></htmltext>
<tokenext>Getting something that allows you to browse code more efficiently certainly helps .
There are tools for doing that .
Another trick is to compile in debug mode , run the code inside a debugger , then break and watch the function call stack .
This can help understand deeply nested code some more .
In the long run however nothing substitutes practice using the codebase .
Even an author can get lost if he spends some years away from the code... Either you just do not remember anymore , or the code was changed so much by someone else 's edits it gets hard to recognize .
Or both .
If the code does not have consistent coding style standards run it thought a indenting program .
You may lose the revision control history but you certainly get a more than reasonable return from it being easier to parse manually .
If it does have a consistent coding style standard , even if it is something you are not used to , probably better to keep it that way .
Cleanup code by refactoring common code blocks out , or doing other code refactoring that reduces line code code and/or increases readability .
Make sure the refactored version is functionally equivalent to the non-refactored version .
Unless you are fixing a bug .
Even if you are fixing a bug document the change just in case something actually relies on bug for bug compatibility .
If you do not have time to do cleanups just keep adding the functionality you need .
Eventually you will have read enough code that you will know the codebase .
If you do not need to add any more functionality , who cares anyway ?</tokentext>
<sentencetext>
Getting something that allows you to browse code more efficiently certainly helps.
There are tools for doing that.
Another trick is to compile in debug mode, run the code inside a debugger, then break and watch the function call stack.
This can help understand deeply nested code some more.
In the long run however nothing substitutes practice using the codebase.
Even an author can get lost if he spends some years away from the code... Either you just do not remember anymore, or the code was changed so much by someone else's edits it gets hard to recognize.
Or both.
If the code does not have consistent coding style standards run it thought a indenting program.
You may lose the revision control history but you certainly get a more than reasonable return from it being easier to parse manually.
If it does have a consistent coding style standard, even if it is something you are not used to, probably better to keep it that way.
Cleanup code by refactoring common code blocks out, or doing other code refactoring that reduces line code code and/or increases readability.
Make sure the refactored version is functionally equivalent to the non-refactored version.
Unless you are fixing a bug.
Even if you are fixing a bug document the change just in case something actually relies on bug for bug compatibility.
If you do not have time to do cleanups just keep adding the functionality you need.
Eventually you will have read enough code that you will know the codebase.
If you do not need to add any more functionality, who cares anyway?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128880</id>
	<title>Re:Not lots of code</title>
	<author>Anonymous</author>
	<datestamp>1266091020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>'Lots' is a relative term.  If you're used to working on projects involving 250,000 lines of code, then sure, 30,000 isn't much... to YOU.  Maybe submitter is used to working on small, concise projects which only had a couple hundred or thousand lines of code. In that case, yes, 30,000 lines of code is a lot to submitter.</p></htmltext>
<tokenext>'Lots ' is a relative term .
If you 're used to working on projects involving 250,000 lines of code , then sure , 30,000 is n't much... to YOU .
Maybe submitter is used to working on small , concise projects which only had a couple hundred or thousand lines of code .
In that case , yes , 30,000 lines of code is a lot to submitter .</tokentext>
<sentencetext>'Lots' is a relative term.
If you're used to working on projects involving 250,000 lines of code, then sure, 30,000 isn't much... to YOU.
Maybe submitter is used to working on small, concise projects which only had a couple hundred or thousand lines of code.
In that case, yes, 30,000 lines of code is a lot to submitter.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125078</id>
	<title>Go through it and comment it</title>
	<author>presidenteloco</author>
	<datestamp>1266091860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Not necessarily end to end, but leave yourself a trail of breadcrumbs<br>as you trace through and learn the code stories.<br>If you can write about it accurately, you understand it. If you<br>can't, you have to dig deeper in that area til you comprehend it enough<br>to summarize it and its quirks accurately.</p><p>I had a prof once who shall remain nameless, though he claims to<br>have "invented" modules. But he did have some good advice. He said,<br>even if you just hacked together some code (or someone else did), you<br>can retrofit software engineering standards onto it by going through it<br>and writing the design document after the fact (assuming the crap didn't<br>come with one.) This not only leaves a legacy of a maintainable project,<br>but allows you to understand the essence of the software and the<br>important decisions that were made in the construction of the software.</p></htmltext>
<tokenext>Not necessarily end to end , but leave yourself a trail of breadcrumbsas you trace through and learn the code stories.If you can write about it accurately , you understand it .
If youca n't , you have to dig deeper in that area til you comprehend it enoughto summarize it and its quirks accurately.I had a prof once who shall remain nameless , though he claims tohave " invented " modules .
But he did have some good advice .
He said,even if you just hacked together some code ( or someone else did ) , youcan retrofit software engineering standards onto it by going through itand writing the design document after the fact ( assuming the crap didn'tcome with one .
) This not only leaves a legacy of a maintainable project,but allows you to understand the essence of the software and theimportant decisions that were made in the construction of the software .</tokentext>
<sentencetext>Not necessarily end to end, but leave yourself a trail of breadcrumbsas you trace through and learn the code stories.If you can write about it accurately, you understand it.
If youcan't, you have to dig deeper in that area til you comprehend it enoughto summarize it and its quirks accurately.I had a prof once who shall remain nameless, though he claims tohave "invented" modules.
But he did have some good advice.
He said,even if you just hacked together some code (or someone else did), youcan retrofit software engineering standards onto it by going through itand writing the design document after the fact (assuming the crap didn'tcome with one.
) This not only leaves a legacy of a maintainable project,but allows you to understand the essence of the software and theimportant decisions that were made in the construction of the software.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31141246</id>
	<title>Re:Use it</title>
	<author>Anonymous</author>
	<datestamp>1266175680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>So this is fine:</p><p>i++;<br>j = i + 4;<nobr> <wbr></nobr>...but this I can't stand:</p><p>j = ++i + 4;</p></div><p>There's a subtlety there in that, in the latter case it is explicit that it means for i to be 1 more than it previously was, and for j to be 4 more than i's <em>new</em> value; whereas in the former case it is entirely plausible that at some stage code might be added in between the two lines, and the relationship between the increases in i and j are no longer together and obviously related.</p></div>
	</htmltext>
<tokenext>So this is fine : i + + ; j = i + 4 ; ...but this I ca n't stand : j = + + i + 4 ; There 's a subtlety there in that , in the latter case it is explicit that it means for i to be 1 more than it previously was , and for j to be 4 more than i 's new value ; whereas in the former case it is entirely plausible that at some stage code might be added in between the two lines , and the relationship between the increases in i and j are no longer together and obviously related .</tokentext>
<sentencetext>So this is fine:i++;j = i + 4; ...but this I can't stand:j = ++i + 4;There's a subtlety there in that, in the latter case it is explicit that it means for i to be 1 more than it previously was, and for j to be 4 more than i's new value; whereas in the former case it is entirely plausible that at some stage code might be added in between the two lines, and the relationship between the increases in i and j are no longer together and obviously related.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123616</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128228</id>
	<title>Step cautiously!</title>
	<author>ZeLonewolf</author>
	<datestamp>1266086220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Just last summer I took over a project with over 250,000 lines of code.  It was a complete disaster of a codebase, a total Rube Goldberg machine... but somehow, after years of poking and prodding and band-aids and what-not, it WORKED...however, even the tinest code change too weeks to happen because the code was so badly written.  The project had a ton of turnover through the years, and from the looks of it many of the coders use conventions from different languages they were familiar with, copy/paste all over the place, bad structure, fragile inheritance schemes, etc., etc.</p><p>So, I did the only thing that made sense.  Started completely from scratch, picking out the parts that were usable as we went.  We haven't finished yet, but I haven't looked back...</p></htmltext>
<tokenext>Just last summer I took over a project with over 250,000 lines of code .
It was a complete disaster of a codebase , a total Rube Goldberg machine... but somehow , after years of poking and prodding and band-aids and what-not , it WORKED...however , even the tinest code change too weeks to happen because the code was so badly written .
The project had a ton of turnover through the years , and from the looks of it many of the coders use conventions from different languages they were familiar with , copy/paste all over the place , bad structure , fragile inheritance schemes , etc. , etc.So , I did the only thing that made sense .
Started completely from scratch , picking out the parts that were usable as we went .
We have n't finished yet , but I have n't looked back.. .</tokentext>
<sentencetext>Just last summer I took over a project with over 250,000 lines of code.
It was a complete disaster of a codebase, a total Rube Goldberg machine... but somehow, after years of poking and prodding and band-aids and what-not, it WORKED...however, even the tinest code change too weeks to happen because the code was so badly written.
The project had a ton of turnover through the years, and from the looks of it many of the coders use conventions from different languages they were familiar with, copy/paste all over the place, bad structure, fragile inheritance schemes, etc., etc.So, I did the only thing that made sense.
Started completely from scratch, picking out the parts that were usable as we went.
We haven't finished yet, but I haven't looked back...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126274</id>
	<title>Re:As a maintenance programmer</title>
	<author>Anonymous</author>
	<datestamp>1266070140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Writen code that "just works" can be done by an idiot, but write code that "just works" as clients think that sould work is another question, doing that to be maintainable is another level.</p></htmltext>
<tokenext>Writen code that " just works " can be done by an idiot , but write code that " just works " as clients think that sould work is another question , doing that to be maintainable is another level .</tokentext>
<sentencetext>Writen code that "just works" can be done by an idiot, but write code that "just works" as clients think that sould work is another question, doing that to be maintainable is another level.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123076</id>
	<title>Me</title>
	<author>Anonymous</author>
	<datestamp>1265984880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>&gt;30-40 thousand lines ?</p><p>You must be kidding. This is a tool. Business Apps are one scale more: 300-400 thousand lines.<br>As for your question: Hire the original developer.<br>No documentation-&gt;Code is not worth a cent. In the business world the documentation should be in the code. approx 1:1 code and comments line.<br>This is the apps that control your money, phone calls, insurance and your airplane tickets. That's the real apps.</p></htmltext>
<tokenext>&gt; 30-40 thousand lines ? You must be kidding .
This is a tool .
Business Apps are one scale more : 300-400 thousand lines.As for your question : Hire the original developer.No documentation- &gt; Code is not worth a cent .
In the business world the documentation should be in the code .
approx 1 : 1 code and comments line.This is the apps that control your money , phone calls , insurance and your airplane tickets .
That 's the real apps .</tokentext>
<sentencetext>&gt;30-40 thousand lines ?You must be kidding.
This is a tool.
Business Apps are one scale more: 300-400 thousand lines.As for your question: Hire the original developer.No documentation-&gt;Code is not worth a cent.
In the business world the documentation should be in the code.
approx 1:1 code and comments line.This is the apps that control your money, phone calls, insurance and your airplane tickets.
That's the real apps.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122256</id>
	<title>It depends on the language</title>
	<author>$RANDOMLUSER</author>
	<datestamp>1265980500000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext>If it's Perl or VB, you might want to consider self-immolation as a first step.</htmltext>
<tokenext>If it 's Perl or VB , you might want to consider self-immolation as a first step .</tokentext>
<sentencetext>If it's Perl or VB, you might want to consider self-immolation as a first step.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127196</id>
	<title>Re:It depends on the language</title>
	<author>Anonymous</author>
	<datestamp>1266078900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I am on a team that maintains a 100,000+ line mod\_perl app that as a memory footprint of over a Gig.<br>None of the original developers are around.<br>We have considered building a time machine to stop the creators from making some of the more abominable design decisions.</p></htmltext>
<tokenext>I am on a team that maintains a 100,000 + line mod \ _perl app that as a memory footprint of over a Gig.None of the original developers are around.We have considered building a time machine to stop the creators from making some of the more abominable design decisions .</tokentext>
<sentencetext>I am on a team that maintains a 100,000+ line mod\_perl app that as a memory footprint of over a Gig.None of the original developers are around.We have considered building a time machine to stop the creators from making some of the more abominable design decisions.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122256</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31130118</id>
	<title>Read And Love</title>
	<author>Anonymous</author>
	<datestamp>1266057540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Check out the excellent article <a href="http://delivery.acm.org/10.1145/1490000/1483108/p26-neville-neil.html?key1=1483108&amp;key2=0210016621&amp;coll=GUIDE&amp;dl=GUIDE&amp;CFID=76089944&amp;CFTOKEN=52847804" title="acm.org" rel="nofollow">Code Spelunking Redux: Is it getting any easier to understand other people&rsquo;s code?</a> [acm.org], and learn to love Doxygen and DTrace (if your language is supported).</p></htmltext>
<tokenext>Check out the excellent article Code Spelunking Redux : Is it getting any easier to understand other people    s code ?
[ acm.org ] , and learn to love Doxygen and DTrace ( if your language is supported ) .</tokentext>
<sentencetext>Check out the excellent article Code Spelunking Redux: Is it getting any easier to understand other people’s code?
[acm.org], and learn to love Doxygen and DTrace (if your language is supported).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122922</id>
	<title>Legacy code == code without unit tests</title>
	<author>PatMcGee</author>
	<datestamp>1265983920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Get a copy of Michael Feathers' book "Working Effectively with Legacy Code".
<br> <br>
I taught a grad / undergrad course using this book. We took a real open-source program as the class project, and the teams made significant changes to it. I thought it worked well.
<br> <br>
Pat</htmltext>
<tokenext>Get a copy of Michael Feathers ' book " Working Effectively with Legacy Code " .
I taught a grad / undergrad course using this book .
We took a real open-source program as the class project , and the teams made significant changes to it .
I thought it worked well .
Pat</tokentext>
<sentencetext>Get a copy of Michael Feathers' book "Working Effectively with Legacy Code".
I taught a grad / undergrad course using this book.
We took a real open-source program as the class project, and the teams made significant changes to it.
I thought it worked well.
Pat</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31133862</id>
	<title>40k isn't huge, but it's not small</title>
	<author>Anonymous</author>
	<datestamp>1266153540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Sorry, but all the people giggling saying 40k lines of code is "small" are just hothead braggers. Aside from maybe the final graduation project or program for your undergraduate thesis, how many of you with CS or CIS 4-year degrees ever had to write even close to 40k while in college? None of ya. Only to then graduate, work for a while, and then act like anything under a million lines is small? Whatever.</p></htmltext>
<tokenext>Sorry , but all the people giggling saying 40k lines of code is " small " are just hothead braggers .
Aside from maybe the final graduation project or program for your undergraduate thesis , how many of you with CS or CIS 4-year degrees ever had to write even close to 40k while in college ?
None of ya .
Only to then graduate , work for a while , and then act like anything under a million lines is small ?
Whatever .</tokentext>
<sentencetext>Sorry, but all the people giggling saying 40k lines of code is "small" are just hothead braggers.
Aside from maybe the final graduation project or program for your undergraduate thesis, how many of you with CS or CIS 4-year degrees ever had to write even close to 40k while in college?
None of ya.
Only to then graduate, work for a while, and then act like anything under a million lines is small?
Whatever.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356</id>
	<title>Tried and True</title>
	<author>Anonymous</author>
	<datestamp>1265980920000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><b>For culinary folks...</b> <br>
The time and money you spend tracing and inserting noodles in the spaghetti will end up being larger than the time it takes to cook a new batch (no pun intended).<br>
<br>
<b>For auto folks...</b> <br>
The time and money you spend bondo-ing, welding, rewiring, duct-taping, and C'n'Cing parts for the car will end up being larger than the time it takes to design and build a new car. (Although restoring an old/vintage car for the sake of nostalgia is a much more pleasing experience than buying a new one).<br>
<br>

Gain an understanding of the purpose of each pivotal region. Know what your desired result should be, then begin the rewriting endeavor.</htmltext>
<tokenext>For culinary folks.. . The time and money you spend tracing and inserting noodles in the spaghetti will end up being larger than the time it takes to cook a new batch ( no pun intended ) .
For auto folks.. . The time and money you spend bondo-ing , welding , rewiring , duct-taping , and C'n'Cing parts for the car will end up being larger than the time it takes to design and build a new car .
( Although restoring an old/vintage car for the sake of nostalgia is a much more pleasing experience than buying a new one ) .
Gain an understanding of the purpose of each pivotal region .
Know what your desired result should be , then begin the rewriting endeavor .</tokentext>
<sentencetext>For culinary folks... 
The time and money you spend tracing and inserting noodles in the spaghetti will end up being larger than the time it takes to cook a new batch (no pun intended).
For auto folks... 
The time and money you spend bondo-ing, welding, rewiring, duct-taping, and C'n'Cing parts for the car will end up being larger than the time it takes to design and build a new car.
(Although restoring an old/vintage car for the sake of nostalgia is a much more pleasing experience than buying a new one).
Gain an understanding of the purpose of each pivotal region.
Know what your desired result should be, then begin the rewriting endeavor.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123744</id>
	<title>What NOT to do</title>
	<author>bit9</author>
	<datestamp>1265990220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Ever seen that demotivational <a href="http://www.despair.com/mis24x30prin.html" title="despair.com" rel="nofollow">poster</a> [despair.com] that says "It could be that the purpose of your life is only to serve as a warning to others." ?</p><p>Well, that was me on my last project. I inherited a codebase of about 1.2 million lines of antequated C code, written by a dozen or so different people over the course of a dozen or so years, for half a dozen different projects. For your benefit, here are a few dos/don'ts that I learned the hard way:</p><p>1. <b>DO NOT</b> try to be a hero and learn the code inside/out all by yourself. Going in, I had a long history of doing exactly that on numerous smaller projects. Turns out 1.2 million lines was <b>WAY</b> beyond my ability to grasp just by pouring over the source code. The whole time I was trying to decipher this massive, seemingly amorphous blob of code all by myself, there were at least 2 or 3 of the previous developers sitting a couple floors up. All I had to do was ask for help, but for a variety of reasons (they are very busy people, I don't want to come off as being incompetent, my own overconfidence, etc), I didn't use that resource nearly as much as I could (and <b>should</b>) have.</p><p>2. <b>DO NOT</b> try to learn the code bottom-up, by diving straight in and trying to put it all together one piece at a time like a giant jigsaw puzzle. Get a good, solid big picture view in your head first. Draw it out. Data flow, logic flow, UML diagrams, whatever it takes for you to <i>really</i> understand it at a high level, <i>before</i> you start reading source code line by line, function by function, class by class.</p><p>3. <b>DO NOT</b> be afraid to make a few assumptions, at least initially. Yes, this may well mean that your high-level mental picture of the code may have some errors that you will need to fix later on, but you need to use your time efficiently. If you can reasonably discern what a given module, file, or function does without having to read every line of code, go ahead and pencil it in on your high level diagram and move on. If you see a source code file named reset\_xyz\_board.c, you can be reasonably sure it's resetting the "xyz" board. No need to fully grasp every little detail right off the bat. There will be time for that later, <i>if and when</i> it becomes necessary. But keep in mind that with any sufficiently large codebase, there are going to be numerous dark corners that you <i>never</i> end up seeing anyway. Why waste time meticulously mapping out every single one of those dark corners when, in all likelihood, you are only ever going to modify a tenth of the code, or maybe a quarter at the most? The more time you waste obsessing about every minute detail, the less time you will have to truly understand the code from a high level.</p><p>4. <b>DO</b> get help from your team! I don't mean the previous developers. If the codebase is large enough that you don't feel you can learn the code all on your own, chances are you aren't the only person assigned to the project. If you are the only person, and your bosses refuse to get you help, then good luck. Otherwise, enlist your fellow developers to help you figure the damn thing out, before you all go off trying to write new code. In my case, I was the team lead and started off with 3 other developers on my team. I was foolish enough to let my ego get in the way, thinking that it somehow wasn't "right" for a team lead to have to rely on his team to help him figure out the existing code (which I probably <i>could</i> have done if not for mistakes 1-3, but that's beside the point). I wanted to be the guru who had a better, clearer understanding of the code than the rest of my team. Why? Because I figured that was part of my role as a team leader, and I didn't think they would respect me as much if I didn't know more than they did. Let's face it, programmers are a meritocratic bunch. Ranks and titles don't equate to respect. Your fellow programmers will invariably treat you with a level of respect that is in direct relation to <i>their estimation</i> of your</p></htmltext>
<tokenext>Ever seen that demotivational poster [ despair.com ] that says " It could be that the purpose of your life is only to serve as a warning to others .
" ? Well , that was me on my last project .
I inherited a codebase of about 1.2 million lines of antequated C code , written by a dozen or so different people over the course of a dozen or so years , for half a dozen different projects .
For your benefit , here are a few dos/don'ts that I learned the hard way : 1 .
DO NOT try to be a hero and learn the code inside/out all by yourself .
Going in , I had a long history of doing exactly that on numerous smaller projects .
Turns out 1.2 million lines was WAY beyond my ability to grasp just by pouring over the source code .
The whole time I was trying to decipher this massive , seemingly amorphous blob of code all by myself , there were at least 2 or 3 of the previous developers sitting a couple floors up .
All I had to do was ask for help , but for a variety of reasons ( they are very busy people , I do n't want to come off as being incompetent , my own overconfidence , etc ) , I did n't use that resource nearly as much as I could ( and should ) have.2 .
DO NOT try to learn the code bottom-up , by diving straight in and trying to put it all together one piece at a time like a giant jigsaw puzzle .
Get a good , solid big picture view in your head first .
Draw it out .
Data flow , logic flow , UML diagrams , whatever it takes for you to really understand it at a high level , before you start reading source code line by line , function by function , class by class.3 .
DO NOT be afraid to make a few assumptions , at least initially .
Yes , this may well mean that your high-level mental picture of the code may have some errors that you will need to fix later on , but you need to use your time efficiently .
If you can reasonably discern what a given module , file , or function does without having to read every line of code , go ahead and pencil it in on your high level diagram and move on .
If you see a source code file named reset \ _xyz \ _board.c , you can be reasonably sure it 's resetting the " xyz " board .
No need to fully grasp every little detail right off the bat .
There will be time for that later , if and when it becomes necessary .
But keep in mind that with any sufficiently large codebase , there are going to be numerous dark corners that you never end up seeing anyway .
Why waste time meticulously mapping out every single one of those dark corners when , in all likelihood , you are only ever going to modify a tenth of the code , or maybe a quarter at the most ?
The more time you waste obsessing about every minute detail , the less time you will have to truly understand the code from a high level.4 .
DO get help from your team !
I do n't mean the previous developers .
If the codebase is large enough that you do n't feel you can learn the code all on your own , chances are you are n't the only person assigned to the project .
If you are the only person , and your bosses refuse to get you help , then good luck .
Otherwise , enlist your fellow developers to help you figure the damn thing out , before you all go off trying to write new code .
In my case , I was the team lead and started off with 3 other developers on my team .
I was foolish enough to let my ego get in the way , thinking that it somehow was n't " right " for a team lead to have to rely on his team to help him figure out the existing code ( which I probably could have done if not for mistakes 1-3 , but that 's beside the point ) .
I wanted to be the guru who had a better , clearer understanding of the code than the rest of my team .
Why ? Because I figured that was part of my role as a team leader , and I did n't think they would respect me as much if I did n't know more than they did .
Let 's face it , programmers are a meritocratic bunch .
Ranks and titles do n't equate to respect .
Your fellow programmers will invariably treat you with a level of respect that is in direct relation to their estimation of your</tokentext>
<sentencetext>Ever seen that demotivational poster [despair.com] that says "It could be that the purpose of your life is only to serve as a warning to others.
" ?Well, that was me on my last project.
I inherited a codebase of about 1.2 million lines of antequated C code, written by a dozen or so different people over the course of a dozen or so years, for half a dozen different projects.
For your benefit, here are a few dos/don'ts that I learned the hard way:1.
DO NOT try to be a hero and learn the code inside/out all by yourself.
Going in, I had a long history of doing exactly that on numerous smaller projects.
Turns out 1.2 million lines was WAY beyond my ability to grasp just by pouring over the source code.
The whole time I was trying to decipher this massive, seemingly amorphous blob of code all by myself, there were at least 2 or 3 of the previous developers sitting a couple floors up.
All I had to do was ask for help, but for a variety of reasons (they are very busy people, I don't want to come off as being incompetent, my own overconfidence, etc), I didn't use that resource nearly as much as I could (and should) have.2.
DO NOT try to learn the code bottom-up, by diving straight in and trying to put it all together one piece at a time like a giant jigsaw puzzle.
Get a good, solid big picture view in your head first.
Draw it out.
Data flow, logic flow, UML diagrams, whatever it takes for you to really understand it at a high level, before you start reading source code line by line, function by function, class by class.3.
DO NOT be afraid to make a few assumptions, at least initially.
Yes, this may well mean that your high-level mental picture of the code may have some errors that you will need to fix later on, but you need to use your time efficiently.
If you can reasonably discern what a given module, file, or function does without having to read every line of code, go ahead and pencil it in on your high level diagram and move on.
If you see a source code file named reset\_xyz\_board.c, you can be reasonably sure it's resetting the "xyz" board.
No need to fully grasp every little detail right off the bat.
There will be time for that later, if and when it becomes necessary.
But keep in mind that with any sufficiently large codebase, there are going to be numerous dark corners that you never end up seeing anyway.
Why waste time meticulously mapping out every single one of those dark corners when, in all likelihood, you are only ever going to modify a tenth of the code, or maybe a quarter at the most?
The more time you waste obsessing about every minute detail, the less time you will have to truly understand the code from a high level.4.
DO get help from your team!
I don't mean the previous developers.
If the codebase is large enough that you don't feel you can learn the code all on your own, chances are you aren't the only person assigned to the project.
If you are the only person, and your bosses refuse to get you help, then good luck.
Otherwise, enlist your fellow developers to help you figure the damn thing out, before you all go off trying to write new code.
In my case, I was the team lead and started off with 3 other developers on my team.
I was foolish enough to let my ego get in the way, thinking that it somehow wasn't "right" for a team lead to have to rely on his team to help him figure out the existing code (which I probably could have done if not for mistakes 1-3, but that's beside the point).
I wanted to be the guru who had a better, clearer understanding of the code than the rest of my team.
Why? Because I figured that was part of my role as a team leader, and I didn't think they would respect me as much if I didn't know more than they did.
Let's face it, programmers are a meritocratic bunch.
Ranks and titles don't equate to respect.
Your fellow programmers will invariably treat you with a level of respect that is in direct relation to their estimation of your</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123428</id>
	<title>Well...</title>
	<author>RobertM1968</author>
	<datestamp>1265987340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>[humor]
</p><p>You could always ask Microsoft... that sounds like almost every piece of software they currently (or even previously) sell or sold (with of course differences in the amounts of code). Maintaining it properly seems to be working fi.....

</p><p>...ummmm, never mind. Perhaps you should simply learn how to market it really well, kill the competition via anti-competitive actions, and kludge on a thing or two so that you can claim you've "improved" it.
</p><p>[/humor]</p></htmltext>
<tokenext>[ humor ] You could always ask Microsoft... that sounds like almost every piece of software they currently ( or even previously ) sell or sold ( with of course differences in the amounts of code ) .
Maintaining it properly seems to be working fi.... . ...ummmm , never mind .
Perhaps you should simply learn how to market it really well , kill the competition via anti-competitive actions , and kludge on a thing or two so that you can claim you 've " improved " it .
[ /humor ]</tokentext>
<sentencetext>[humor]
You could always ask Microsoft... that sounds like almost every piece of software they currently (or even previously) sell or sold (with of course differences in the amounts of code).
Maintaining it properly seems to be working fi.....

...ummmm, never mind.
Perhaps you should simply learn how to market it really well, kill the competition via anti-competitive actions, and kludge on a thing or two so that you can claim you've "improved" it.
[/humor]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123230</id>
	<title>Re:Use it</title>
	<author>phantomfive</author>
	<datestamp>1265985900000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p>What do you think about intermediate variables that are not strictly necessary?</p></div><p>Use them if they make things clearer for someone reading the code, otherwise don't.  For example, you can write:<br> <br>
<tt>
screen.displayName = user.firstName + user.lastName;
</tt> <br> <br>
or you can write<br> <br>
<tt>
String fullName = user.FirstName + user.lastName;
<br>
screen.displayName = fullName;
</tt> <br> <br>
Thus making it more clear to someone reading that you are trying to use the full name.  That is probably not the best example because anyone would probably understand that <tt>user.firstName + user.lastName</tt> is the full name, but I think you can see the main point, that sometimes it can be easier to read a few meaningfully named intermediate variables than a long equation.  If it isn't easier to read, don't do it.  But really when I read code, or even write it, I am willing to conform to either way of doing it if someone else feels strongly about it, because that is far less important than things like flexibility of major structures in the code.</p></div>
	</htmltext>
<tokenext>What do you think about intermediate variables that are not strictly necessary ? Use them if they make things clearer for someone reading the code , otherwise do n't .
For example , you can write : screen.displayName = user.firstName + user.lastName ; or you can write String fullName = user.FirstName + user.lastName ; screen.displayName = fullName ; Thus making it more clear to someone reading that you are trying to use the full name .
That is probably not the best example because anyone would probably understand that user.firstName + user.lastName is the full name , but I think you can see the main point , that sometimes it can be easier to read a few meaningfully named intermediate variables than a long equation .
If it is n't easier to read , do n't do it .
But really when I read code , or even write it , I am willing to conform to either way of doing it if someone else feels strongly about it , because that is far less important than things like flexibility of major structures in the code .</tokentext>
<sentencetext>What do you think about intermediate variables that are not strictly necessary?Use them if they make things clearer for someone reading the code, otherwise don't.
For example, you can write: 

screen.displayName = user.firstName + user.lastName;
  
or you can write 

String fullName = user.FirstName + user.lastName;

screen.displayName = fullName;
  
Thus making it more clear to someone reading that you are trying to use the full name.
That is probably not the best example because anyone would probably understand that user.firstName + user.lastName is the full name, but I think you can see the main point, that sometimes it can be easier to read a few meaningfully named intermediate variables than a long equation.
If it isn't easier to read, don't do it.
But really when I read code, or even write it, I am willing to conform to either way of doing it if someone else feels strongly about it, because that is far less important than things like flexibility of major structures in the code.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31154118</id>
	<title>Use Code Rocket!</title>
	<author>InspirationalThingy</author>
	<datestamp>1266327000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>
This is a problem I have encountered several times in the past, inheriting reasonably large, poorly documented code bases. It can be an interesting personal challenge, deciphering someone else's code, but not when you are working to a timescale.<br> <br>

I became so frustrated that I decided it was time to try and do something about it.<br> <br>

As a result, we (myself and a couple of other developers) have developed a new software tool which aims to cut through legacy code, to visualise it in an abstract way, and to allow you to build a picture of what its doing quickly and efficiently.<br> <br>

In simple terms our tool (named 'Code Rocket') is a detailed design documentation tool - kind of like doxygen, but taking documentation a step further.<br> <br>

We use it to prevent the code from becoming a legacy nightmare in the first place (by ensuring it is structured and documented to a high standard but with limited overheads for software developers during development) and to reverse engineer the meaning of any existing legacy code to guide us through an understanding of it. There are many other side benefits as it turns out relating to project management, review, communication, but the main thing is that I now feel a little more comfortable when presented with a batch of legacy code to investigate. I also agree with the recommendations of building in unit tests.<br> <br>

If anyone is interested in checking out our tool, you'll find it at the following web site:
<a href="http://www.rapidqualitysystems.com/" title="rapidqualitysystems.com" rel="nofollow">http://www.rapidqualitysystems.com/</a> [rapidqualitysystems.com]</htmltext>
<tokenext>This is a problem I have encountered several times in the past , inheriting reasonably large , poorly documented code bases .
It can be an interesting personal challenge , deciphering someone else 's code , but not when you are working to a timescale .
I became so frustrated that I decided it was time to try and do something about it .
As a result , we ( myself and a couple of other developers ) have developed a new software tool which aims to cut through legacy code , to visualise it in an abstract way , and to allow you to build a picture of what its doing quickly and efficiently .
In simple terms our tool ( named 'Code Rocket ' ) is a detailed design documentation tool - kind of like doxygen , but taking documentation a step further .
We use it to prevent the code from becoming a legacy nightmare in the first place ( by ensuring it is structured and documented to a high standard but with limited overheads for software developers during development ) and to reverse engineer the meaning of any existing legacy code to guide us through an understanding of it .
There are many other side benefits as it turns out relating to project management , review , communication , but the main thing is that I now feel a little more comfortable when presented with a batch of legacy code to investigate .
I also agree with the recommendations of building in unit tests .
If anyone is interested in checking out our tool , you 'll find it at the following web site : http : //www.rapidqualitysystems.com/ [ rapidqualitysystems.com ]</tokentext>
<sentencetext>
This is a problem I have encountered several times in the past, inheriting reasonably large, poorly documented code bases.
It can be an interesting personal challenge, deciphering someone else's code, but not when you are working to a timescale.
I became so frustrated that I decided it was time to try and do something about it.
As a result, we (myself and a couple of other developers) have developed a new software tool which aims to cut through legacy code, to visualise it in an abstract way, and to allow you to build a picture of what its doing quickly and efficiently.
In simple terms our tool (named 'Code Rocket') is a detailed design documentation tool - kind of like doxygen, but taking documentation a step further.
We use it to prevent the code from becoming a legacy nightmare in the first place (by ensuring it is structured and documented to a high standard but with limited overheads for software developers during development) and to reverse engineer the meaning of any existing legacy code to guide us through an understanding of it.
There are many other side benefits as it turns out relating to project management, review, communication, but the main thing is that I now feel a little more comfortable when presented with a batch of legacy code to investigate.
I also agree with the recommendations of building in unit tests.
If anyone is interested in checking out our tool, you'll find it at the following web site:
http://www.rapidqualitysystems.com/ [rapidqualitysystems.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125198</id>
	<title>Don't panic. Focus. Cscope, Wiki, and printfs</title>
	<author>Sarusa</author>
	<datestamp>1266093660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This has happened to me several times, and again just recently. I'm not sure how many lines of code it was this time (I don't really care), but several thousand files (I do care about the structure). 'This is your new project, we have some stuff we need done ASAP'. The big constraints are:</p><p>
&nbsp; &nbsp; &nbsp; - They want you to start doing stuff right away. That's usually a given.<br>
&nbsp; &nbsp; &nbsp; - Therefore you do not have time to fully understand this code. You do not have time to do a full dissection. Just give up the idea that you can even do so in the short term; that will just paralyze you.<br>
&nbsp; &nbsp; &nbsp; - Very little useful documentation. Read it if there is any, but keep in mind that it is usually out of date and therefore a filthy lie.</p><p>
&nbsp; What you need is a good understanding of the parts of this code that are important right now and some high level overview. If you knock off enough of the little things you will end up learning the whole thing. In this way you gain enough confidence to move forward. So, get cracking:</p><p>
&nbsp; &nbsp; - Make a safe copy. If you're lucky it's already in version control. If not, do it yourself. Check in your test stuff fairly frequently (not in the main trunk!) because you will be breaking things often at first.<br>
&nbsp; &nbsp; - Use cscope or any other tool you like that will let you hop around the code like hyperlinks. cscope lets you do the following very important things: find the definition for this thing (method, structure, #define, whatever). Find all places that are calling something. Find some text anywhere in the code base. Find a file anywhere in the code base.  You need this integrated into your editor so you can do all this without thinking - you can be cruising along, hit a reference to an unfamiliar but important looking datatype or method and just hit a few keys and go to the definition, wherever it is. And then pop back. If you're using Visual Studio then this is already built in, as much as I hate VS otherwise. cscope is an easy addition to emacs, I imagine for vi too. As a last resort, stand alone cscope, but it is so much slower than having it in your chosen editor.<br>
&nbsp; &nbsp; - Add plenty of debugging printfs in areas of code you're interested in. #define a macro for it so you can turn them on or off easily. You can run it under a debugger, but I usually find that takes much longer to step through unless you know exactly what you're looking for already. And with the printfs you will soon develop a feel for what's going on and what values you expect to see. Debugging printfs are like a heartbeat for the code.<br>
&nbsp; &nbsp; - Take notes in a wiki or whatever you prefer the general structure of the program - mostly which areas of the code do critical things that you're interested in, like common/engine/pp.c contains the paper path motor and encoder logic. Or anything else important you find.<br>
&nbsp; &nbsp; - Start solving problems. You won't learn the whole codebase at once by zeroing in on a specific issue to fix, but you will learn subsystems fairly well that way. There should be sufficient separation of logic unless the code is hopelessly broken (which is possible). That's the big thing. Don't worry and get paralyzed if you don't understand it all right away, just work on understanding the bits you need right now and eventually you'll build up a picture of the whole thing.</p><p>I realize there are people who are going to freak out at the idea that you would go in and poke at things before you fully understand everything, but unless you have the luxury of unlimited time, that's not an option. Someone up above suggested writing unit tests for existing code, which is good idea in general, but is probably far more time consuming than you have been given time for. Try writing unit tests for the area you are working on right now if you have the time. It's possible the codebase is so broken that the little changes you are making here are having adverse effects elsewhere, but all you can do is try. Eventually as you knock off issues you'll gain confidence and knowledge and before you know it people will be coming to you with questions about the codebase.</p></htmltext>
<tokenext>This has happened to me several times , and again just recently .
I 'm not sure how many lines of code it was this time ( I do n't really care ) , but several thousand files ( I do care about the structure ) .
'This is your new project , we have some stuff we need done ASAP' .
The big constraints are :       - They want you to start doing stuff right away .
That 's usually a given .
      - Therefore you do not have time to fully understand this code .
You do not have time to do a full dissection .
Just give up the idea that you can even do so in the short term ; that will just paralyze you .
      - Very little useful documentation .
Read it if there is any , but keep in mind that it is usually out of date and therefore a filthy lie .
  What you need is a good understanding of the parts of this code that are important right now and some high level overview .
If you knock off enough of the little things you will end up learning the whole thing .
In this way you gain enough confidence to move forward .
So , get cracking :     - Make a safe copy .
If you 're lucky it 's already in version control .
If not , do it yourself .
Check in your test stuff fairly frequently ( not in the main trunk !
) because you will be breaking things often at first .
    - Use cscope or any other tool you like that will let you hop around the code like hyperlinks .
cscope lets you do the following very important things : find the definition for this thing ( method , structure , # define , whatever ) .
Find all places that are calling something .
Find some text anywhere in the code base .
Find a file anywhere in the code base .
You need this integrated into your editor so you can do all this without thinking - you can be cruising along , hit a reference to an unfamiliar but important looking datatype or method and just hit a few keys and go to the definition , wherever it is .
And then pop back .
If you 're using Visual Studio then this is already built in , as much as I hate VS otherwise .
cscope is an easy addition to emacs , I imagine for vi too .
As a last resort , stand alone cscope , but it is so much slower than having it in your chosen editor .
    - Add plenty of debugging printfs in areas of code you 're interested in .
# define a macro for it so you can turn them on or off easily .
You can run it under a debugger , but I usually find that takes much longer to step through unless you know exactly what you 're looking for already .
And with the printfs you will soon develop a feel for what 's going on and what values you expect to see .
Debugging printfs are like a heartbeat for the code .
    - Take notes in a wiki or whatever you prefer the general structure of the program - mostly which areas of the code do critical things that you 're interested in , like common/engine/pp.c contains the paper path motor and encoder logic .
Or anything else important you find .
    - Start solving problems .
You wo n't learn the whole codebase at once by zeroing in on a specific issue to fix , but you will learn subsystems fairly well that way .
There should be sufficient separation of logic unless the code is hopelessly broken ( which is possible ) .
That 's the big thing .
Do n't worry and get paralyzed if you do n't understand it all right away , just work on understanding the bits you need right now and eventually you 'll build up a picture of the whole thing.I realize there are people who are going to freak out at the idea that you would go in and poke at things before you fully understand everything , but unless you have the luxury of unlimited time , that 's not an option .
Someone up above suggested writing unit tests for existing code , which is good idea in general , but is probably far more time consuming than you have been given time for .
Try writing unit tests for the area you are working on right now if you have the time .
It 's possible the codebase is so broken that the little changes you are making here are having adverse effects elsewhere , but all you can do is try .
Eventually as you knock off issues you 'll gain confidence and knowledge and before you know it people will be coming to you with questions about the codebase .</tokentext>
<sentencetext>This has happened to me several times, and again just recently.
I'm not sure how many lines of code it was this time (I don't really care), but several thousand files (I do care about the structure).
'This is your new project, we have some stuff we need done ASAP'.
The big constraints are:
      - They want you to start doing stuff right away.
That's usually a given.
      - Therefore you do not have time to fully understand this code.
You do not have time to do a full dissection.
Just give up the idea that you can even do so in the short term; that will just paralyze you.
      - Very little useful documentation.
Read it if there is any, but keep in mind that it is usually out of date and therefore a filthy lie.
  What you need is a good understanding of the parts of this code that are important right now and some high level overview.
If you knock off enough of the little things you will end up learning the whole thing.
In this way you gain enough confidence to move forward.
So, get cracking:
    - Make a safe copy.
If you're lucky it's already in version control.
If not, do it yourself.
Check in your test stuff fairly frequently (not in the main trunk!
) because you will be breaking things often at first.
    - Use cscope or any other tool you like that will let you hop around the code like hyperlinks.
cscope lets you do the following very important things: find the definition for this thing (method, structure, #define, whatever).
Find all places that are calling something.
Find some text anywhere in the code base.
Find a file anywhere in the code base.
You need this integrated into your editor so you can do all this without thinking - you can be cruising along, hit a reference to an unfamiliar but important looking datatype or method and just hit a few keys and go to the definition, wherever it is.
And then pop back.
If you're using Visual Studio then this is already built in, as much as I hate VS otherwise.
cscope is an easy addition to emacs, I imagine for vi too.
As a last resort, stand alone cscope, but it is so much slower than having it in your chosen editor.
    - Add plenty of debugging printfs in areas of code you're interested in.
#define a macro for it so you can turn them on or off easily.
You can run it under a debugger, but I usually find that takes much longer to step through unless you know exactly what you're looking for already.
And with the printfs you will soon develop a feel for what's going on and what values you expect to see.
Debugging printfs are like a heartbeat for the code.
    - Take notes in a wiki or whatever you prefer the general structure of the program - mostly which areas of the code do critical things that you're interested in, like common/engine/pp.c contains the paper path motor and encoder logic.
Or anything else important you find.
    - Start solving problems.
You won't learn the whole codebase at once by zeroing in on a specific issue to fix, but you will learn subsystems fairly well that way.
There should be sufficient separation of logic unless the code is hopelessly broken (which is possible).
That's the big thing.
Don't worry and get paralyzed if you don't understand it all right away, just work on understanding the bits you need right now and eventually you'll build up a picture of the whole thing.I realize there are people who are going to freak out at the idea that you would go in and poke at things before you fully understand everything, but unless you have the luxury of unlimited time, that's not an option.
Someone up above suggested writing unit tests for existing code, which is good idea in general, but is probably far more time consuming than you have been given time for.
Try writing unit tests for the area you are working on right now if you have the time.
It's possible the codebase is so broken that the little changes you are making here are having adverse effects elsewhere, but all you can do is try.
Eventually as you knock off issues you'll gain confidence and knowledge and before you know it people will be coming to you with questions about the codebase.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124960</id>
	<title>I've been there</title>
	<author>Anonymous</author>
	<datestamp>1266003360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>A few years ago i was the maintainer for a couple of unix services. They ran on embedded machines and were 25-30k lines a pop. the best thing I found to cope with it was getting the code in a nice IDE (the cdt for eclipse) and using a visualization package to understand how all the data structures were laid out, I think i used graphviz.</p></htmltext>
<tokenext>A few years ago i was the maintainer for a couple of unix services .
They ran on embedded machines and were 25-30k lines a pop .
the best thing I found to cope with it was getting the code in a nice IDE ( the cdt for eclipse ) and using a visualization package to understand how all the data structures were laid out , I think i used graphviz .</tokentext>
<sentencetext>A few years ago i was the maintainer for a couple of unix services.
They ran on embedded machines and were 25-30k lines a pop.
the best thing I found to cope with it was getting the code in a nice IDE (the cdt for eclipse) and using a visualization package to understand how all the data structures were laid out, I think i used graphviz.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122710</id>
	<title>Re:Use it</title>
	<author>EvanED</author>
	<datestamp>1265982600000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p><i>Am I off base here? What do you think about intermediate variables that are not strictly necessary?</i></p><p>I can't say you're off base per se (I don't have nearly enough production dev experience to make statements like that, and even if I did, I couldn't speak for everyone), but my personal style is not quite the complete opposite of yours.</p><p>I pretty heavily use intermediate variables. Why? A couple big reasons. One, if you give the temporary variables decent names, they serve as additional documentation. Two, if you're debugging, you can look at those intermediate values in a debugger (or log them) <i>much</i> easier than you could if they weren't explicitly stored somewhere. In most graphical debuggers you can just hover the mouse over a variable and see its value; if you didn't have that variable, you'd have to enter the expression in the immediate window or set up a watch or something like that.</p></htmltext>
<tokenext>Am I off base here ?
What do you think about intermediate variables that are not strictly necessary ? I ca n't say you 're off base per se ( I do n't have nearly enough production dev experience to make statements like that , and even if I did , I could n't speak for everyone ) , but my personal style is not quite the complete opposite of yours.I pretty heavily use intermediate variables .
Why ? A couple big reasons .
One , if you give the temporary variables decent names , they serve as additional documentation .
Two , if you 're debugging , you can look at those intermediate values in a debugger ( or log them ) much easier than you could if they were n't explicitly stored somewhere .
In most graphical debuggers you can just hover the mouse over a variable and see its value ; if you did n't have that variable , you 'd have to enter the expression in the immediate window or set up a watch or something like that .</tokentext>
<sentencetext>Am I off base here?
What do you think about intermediate variables that are not strictly necessary?I can't say you're off base per se (I don't have nearly enough production dev experience to make statements like that, and even if I did, I couldn't speak for everyone), but my personal style is not quite the complete opposite of yours.I pretty heavily use intermediate variables.
Why? A couple big reasons.
One, if you give the temporary variables decent names, they serve as additional documentation.
Two, if you're debugging, you can look at those intermediate values in a debugger (or log them) much easier than you could if they weren't explicitly stored somewhere.
In most graphical debuggers you can just hover the mouse over a variable and see its value; if you didn't have that variable, you'd have to enter the expression in the immediate window or set up a watch or something like that.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124428</id>
	<title>Re:Not lots of code</title>
	<author>Anonymous</author>
	<datestamp>1265997120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>1st of all 250,000 lines of code is not a lot of code, you sissies dare venture into softswitch land, where you'd find 1.5 million lines of code....good luck learning that</p></htmltext>
<tokenext>1st of all 250,000 lines of code is not a lot of code , you sissies dare venture into softswitch land , where you 'd find 1.5 million lines of code....good luck learning that</tokentext>
<sentencetext>1st of all 250,000 lines of code is not a lot of code, you sissies dare venture into softswitch land, where you'd find 1.5 million lines of code....good luck learning that</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122476</id>
	<title>Piker....</title>
	<author>Anonymous</author>
	<datestamp>1265981520000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext>Why are you whining about that small of a code base.  GCC is far larger and I've ported it to several systems some that required rewriting core elements of the code generators.  It's a few million lines of code.  Thirty to forty thousand lines of code is a small program and probably a single executable at that.  Build yourself a picture of the major elements of the code and from that map you can get anywhere you want.  It's only computer science after all it's not rocket...oh sorry some of the code I've written is in a rocket so I guess it could be rocket science too.  Well you get the picture.  Just like any new city you need a map.  Once you have that it's cake.  Oh and the cake is a lie...</htmltext>
<tokenext>Why are you whining about that small of a code base .
GCC is far larger and I 've ported it to several systems some that required rewriting core elements of the code generators .
It 's a few million lines of code .
Thirty to forty thousand lines of code is a small program and probably a single executable at that .
Build yourself a picture of the major elements of the code and from that map you can get anywhere you want .
It 's only computer science after all it 's not rocket...oh sorry some of the code I 've written is in a rocket so I guess it could be rocket science too .
Well you get the picture .
Just like any new city you need a map .
Once you have that it 's cake .
Oh and the cake is a lie.. .</tokentext>
<sentencetext>Why are you whining about that small of a code base.
GCC is far larger and I've ported it to several systems some that required rewriting core elements of the code generators.
It's a few million lines of code.
Thirty to forty thousand lines of code is a small program and probably a single executable at that.
Build yourself a picture of the major elements of the code and from that map you can get anywhere you want.
It's only computer science after all it's not rocket...oh sorry some of the code I've written is in a rocket so I guess it could be rocket science too.
Well you get the picture.
Just like any new city you need a map.
Once you have that it's cake.
Oh and the cake is a lie...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</id>
	<title>Not lots of code</title>
	<author>www.sorehands.com</author>
	<datestamp>1265980560000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>First of all, 30-40,000 lines of code is not lots of code. Try, 250,000 of code.</p><p>To start, use a good programming editor/environment (Xcode, Vslick, Visual Studio, etc.) that gives you the ability to easily go to definition or references to variables, functions, structs and such.  Run some sort of profiler or flowchart type program on it to get a high level view of the code and how it fits together. If you can get the person(s) who worked on it before you to give you an idea of it fits together.</p></htmltext>
<tokenext>First of all , 30-40,000 lines of code is not lots of code .
Try , 250,000 of code.To start , use a good programming editor/environment ( Xcode , Vslick , Visual Studio , etc .
) that gives you the ability to easily go to definition or references to variables , functions , structs and such .
Run some sort of profiler or flowchart type program on it to get a high level view of the code and how it fits together .
If you can get the person ( s ) who worked on it before you to give you an idea of it fits together .</tokentext>
<sentencetext>First of all, 30-40,000 lines of code is not lots of code.
Try, 250,000 of code.To start, use a good programming editor/environment (Xcode, Vslick, Visual Studio, etc.
) that gives you the ability to easily go to definition or references to variables, functions, structs and such.
Run some sort of profiler or flowchart type program on it to get a high level view of the code and how it fits together.
If you can get the person(s) who worked on it before you to give you an idea of it fits together.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31131706</id>
	<title>Re:Use it</title>
	<author>hitchhacker</author>
	<datestamp>1266073200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>What do you think about intermediate variables that are not strictly necessary?</p></div><p>I'll often find myself coding some physics equations from specifications written on paper.   Obviously, they are always written in math notations.  What I end up doing, if not limited by cpu/ram, is to create a stack variable for each term in the equations.  Basically, I'll try to make the code look as much like the paper specs as possible.  The specs will ALWAYS change, and trying to figure out how the two relate some years later is a real pita.  Also, I'll always preface everything with some comment like "The following is from foobar specs dated Jan 1st  2002" for the reverse reasons.
<br> <br>
-metric</p></div>
	</htmltext>
<tokenext>What do you think about intermediate variables that are not strictly necessary ? I 'll often find myself coding some physics equations from specifications written on paper .
Obviously , they are always written in math notations .
What I end up doing , if not limited by cpu/ram , is to create a stack variable for each term in the equations .
Basically , I 'll try to make the code look as much like the paper specs as possible .
The specs will ALWAYS change , and trying to figure out how the two relate some years later is a real pita .
Also , I 'll always preface everything with some comment like " The following is from foobar specs dated Jan 1st 2002 " for the reverse reasons .
-metric</tokentext>
<sentencetext>What do you think about intermediate variables that are not strictly necessary?I'll often find myself coding some physics equations from specifications written on paper.
Obviously, they are always written in math notations.
What I end up doing, if not limited by cpu/ram, is to create a stack variable for each term in the equations.
Basically, I'll try to make the code look as much like the paper specs as possible.
The specs will ALWAYS change, and trying to figure out how the two relate some years later is a real pita.
Also, I'll always preface everything with some comment like "The following is from foobar specs dated Jan 1st  2002" for the reverse reasons.
-metric
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123616</id>
	<title>Re:Use it</title>
	<author>ciggieposeur</author>
	<datestamp>1265989020000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p><i>What do you think about intermediate variables that are not strictly necessary?</i></p><p>My general rules of thumb:</p><p>1) I don't care how many variables are declared, so long as each makes sense on its own.  Like another poster's example, 'fullName' is perfectly acceptable (especially for i18n/l10n aware code that may have different rules for generating a name).</p><p>2) I ABSOLUTELY HATE clever arithmetic / pointer arithmetic / expressions all crunched into one line that can be split out.  Example:  in C-like languages that support pre- and post-increment, I expect the code to use only one or the other consistently, and never mix it with another expression.  So this is fine:</p><p>i++;<br>j = i + 4;<nobr> <wbr></nobr>...but this I can't stand:</p><p>j = ++i + 4;</p><p>#2 I picked up from a very experienced developer who pointed out that making the code harder to read is never worth it, the compiler produces the same code as the easy-to-read version.  And that making code that looks 'too easy to be clever' is quite a bit harder than making code that looks 'too clever to always work'.</p></htmltext>
<tokenext>What do you think about intermediate variables that are not strictly necessary ? My general rules of thumb : 1 ) I do n't care how many variables are declared , so long as each makes sense on its own .
Like another poster 's example , 'fullName ' is perfectly acceptable ( especially for i18n/l10n aware code that may have different rules for generating a name ) .2 ) I ABSOLUTELY HATE clever arithmetic / pointer arithmetic / expressions all crunched into one line that can be split out .
Example : in C-like languages that support pre- and post-increment , I expect the code to use only one or the other consistently , and never mix it with another expression .
So this is fine : i + + ; j = i + 4 ; ...but this I ca n't stand : j = + + i + 4 ; # 2 I picked up from a very experienced developer who pointed out that making the code harder to read is never worth it , the compiler produces the same code as the easy-to-read version .
And that making code that looks 'too easy to be clever ' is quite a bit harder than making code that looks 'too clever to always work' .</tokentext>
<sentencetext>What do you think about intermediate variables that are not strictly necessary?My general rules of thumb:1) I don't care how many variables are declared, so long as each makes sense on its own.
Like another poster's example, 'fullName' is perfectly acceptable (especially for i18n/l10n aware code that may have different rules for generating a name).2) I ABSOLUTELY HATE clever arithmetic / pointer arithmetic / expressions all crunched into one line that can be split out.
Example:  in C-like languages that support pre- and post-increment, I expect the code to use only one or the other consistently, and never mix it with another expression.
So this is fine:i++;j = i + 4; ...but this I can't stand:j = ++i + 4;#2 I picked up from a very experienced developer who pointed out that making the code harder to read is never worth it, the compiler produces the same code as the easy-to-read version.
And that making code that looks 'too easy to be clever' is quite a bit harder than making code that looks 'too clever to always work'.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123524</id>
	<title>Re:That's small</title>
	<author>Kagetsuki</author>
	<datestamp>1265988240000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>25 Million lines compiled in 3 hours is actually pretty fast (unless you are talking about say assembing 25M lines of ASM). <br>
<br>
An associate of mine was working at a very high-tech electric (as in production and distribution of electricity) company. Apparently they had this very complex control system for a huge proprietary piece of hardware that was basically the core of the control rooms. It had to take in data from all sorts of different devices spread out across 100's of kilometers over a variety of proprietary protocols, make sense of all that data, try and figure out what the most likely scenarios for failures were and automatically implement control scenarios to mitigate damage or keep parts of the system running etc. So the story is the thing was written in a combination of C and assembler, and the file count alone was in the hundreds of thousands. They had two extremely beefy boxes set up to just do compiles, incremental compiles and re linking taking a few hours and clean compiles taking basically an entire work day (which is why they had two boxes, so they could start one compile after the other so different people could test their changes more often). The thing is to test their changes they actually had a small control room and a collection of devices on a grid they used to test, and to push the new binaries and data files and get a test set up would take hours as well. Needless to say most of the developers would basically just live in the office during the last month or so of development, but the facility was running 24 hours a day either way so they had a full service cafeteria, lounges, etc. all in the building. Anyway, THAT is the biggest code base I have ever heard of; and I'd bet there are quite a few similar situations around the world.</htmltext>
<tokenext>25 Million lines compiled in 3 hours is actually pretty fast ( unless you are talking about say assembing 25M lines of ASM ) .
An associate of mine was working at a very high-tech electric ( as in production and distribution of electricity ) company .
Apparently they had this very complex control system for a huge proprietary piece of hardware that was basically the core of the control rooms .
It had to take in data from all sorts of different devices spread out across 100 's of kilometers over a variety of proprietary protocols , make sense of all that data , try and figure out what the most likely scenarios for failures were and automatically implement control scenarios to mitigate damage or keep parts of the system running etc .
So the story is the thing was written in a combination of C and assembler , and the file count alone was in the hundreds of thousands .
They had two extremely beefy boxes set up to just do compiles , incremental compiles and re linking taking a few hours and clean compiles taking basically an entire work day ( which is why they had two boxes , so they could start one compile after the other so different people could test their changes more often ) .
The thing is to test their changes they actually had a small control room and a collection of devices on a grid they used to test , and to push the new binaries and data files and get a test set up would take hours as well .
Needless to say most of the developers would basically just live in the office during the last month or so of development , but the facility was running 24 hours a day either way so they had a full service cafeteria , lounges , etc .
all in the building .
Anyway , THAT is the biggest code base I have ever heard of ; and I 'd bet there are quite a few similar situations around the world .</tokentext>
<sentencetext>25 Million lines compiled in 3 hours is actually pretty fast (unless you are talking about say assembing 25M lines of ASM).
An associate of mine was working at a very high-tech electric (as in production and distribution of electricity) company.
Apparently they had this very complex control system for a huge proprietary piece of hardware that was basically the core of the control rooms.
It had to take in data from all sorts of different devices spread out across 100's of kilometers over a variety of proprietary protocols, make sense of all that data, try and figure out what the most likely scenarios for failures were and automatically implement control scenarios to mitigate damage or keep parts of the system running etc.
So the story is the thing was written in a combination of C and assembler, and the file count alone was in the hundreds of thousands.
They had two extremely beefy boxes set up to just do compiles, incremental compiles and re linking taking a few hours and clean compiles taking basically an entire work day (which is why they had two boxes, so they could start one compile after the other so different people could test their changes more often).
The thing is to test their changes they actually had a small control room and a collection of devices on a grid they used to test, and to push the new binaries and data files and get a test set up would take hours as well.
Needless to say most of the developers would basically just live in the office during the last month or so of development, but the facility was running 24 hours a day either way so they had a full service cafeteria, lounges, etc.
all in the building.
Anyway, THAT is the biggest code base I have ever heard of; and I'd bet there are quite a few similar situations around the world.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31133354</id>
	<title>Learn only what you need</title>
	<author>softegg</author>
	<datestamp>1266143520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I used to port Japanese RPG games into English for Working Designs, which were similar if not larger code bases. All the comments were in Japanese, and frequently many of the tools used to build the product and assets were missing.</p><p>The way I dealt with it was to only focus on the problem I was trying to solve, and not worry about the rest of the code. The poster who said to backup the code in a VCS was right on... once you know you have a stable base to go back to, you can try all the changes you want.</p><p>If you approach the code with a goal, you can then think about likely places where that code would be. Grep is your friend. If the code has embedded strings, you can search for those strings. Otherwise, you can find the handles for those strings, and search for those. If it is some sort of I/O or database access, search on those call names. Frequently there are naming conventions that you can learn and use to find stuff.</p><p>The idea the earlier poster said about putting breakpoints in and/or stepping through the code was right, this is also a very useful practice. It is much easier to follow the flow if can step through it, especially with C++, where inheritance can often leave one baffled as to which code will actually run.</p><p>Following main (or your language equivalent) and then drilling down is sometimes useful, but it is often easier to find the bottom and work your way back out.</p><p>Watchpoints can be really useful. Find a variable with a value that interests you, and put a watchpoint on it so that it will break when that memory is accessed. A great way to see which routines are involved.</p><p>If all else fails, pepper the code with print (or logging) statements and see what shows up. Try to narrow down what you are looking for.</p><p>Another useful technique is to comment out a section of code and see where the compile breaks to find dependencies.</p><p>As you figure stuff out, add comments. Perhaps also keep a file of notes when you find stuff or figure out how things work.</p><p>As long as you are focused on solving a particular problem, the code base isn't so unreasonable, because you don't care about most of it. As you knock down each problem, you learn a little more about the structure of the code.</p><p>Remember, programming is the art of breaking problems down into smaller problems until they disappear.</p></htmltext>
<tokenext>I used to port Japanese RPG games into English for Working Designs , which were similar if not larger code bases .
All the comments were in Japanese , and frequently many of the tools used to build the product and assets were missing.The way I dealt with it was to only focus on the problem I was trying to solve , and not worry about the rest of the code .
The poster who said to backup the code in a VCS was right on... once you know you have a stable base to go back to , you can try all the changes you want.If you approach the code with a goal , you can then think about likely places where that code would be .
Grep is your friend .
If the code has embedded strings , you can search for those strings .
Otherwise , you can find the handles for those strings , and search for those .
If it is some sort of I/O or database access , search on those call names .
Frequently there are naming conventions that you can learn and use to find stuff.The idea the earlier poster said about putting breakpoints in and/or stepping through the code was right , this is also a very useful practice .
It is much easier to follow the flow if can step through it , especially with C + + , where inheritance can often leave one baffled as to which code will actually run.Following main ( or your language equivalent ) and then drilling down is sometimes useful , but it is often easier to find the bottom and work your way back out.Watchpoints can be really useful .
Find a variable with a value that interests you , and put a watchpoint on it so that it will break when that memory is accessed .
A great way to see which routines are involved.If all else fails , pepper the code with print ( or logging ) statements and see what shows up .
Try to narrow down what you are looking for.Another useful technique is to comment out a section of code and see where the compile breaks to find dependencies.As you figure stuff out , add comments .
Perhaps also keep a file of notes when you find stuff or figure out how things work.As long as you are focused on solving a particular problem , the code base is n't so unreasonable , because you do n't care about most of it .
As you knock down each problem , you learn a little more about the structure of the code.Remember , programming is the art of breaking problems down into smaller problems until they disappear .</tokentext>
<sentencetext>I used to port Japanese RPG games into English for Working Designs, which were similar if not larger code bases.
All the comments were in Japanese, and frequently many of the tools used to build the product and assets were missing.The way I dealt with it was to only focus on the problem I was trying to solve, and not worry about the rest of the code.
The poster who said to backup the code in a VCS was right on... once you know you have a stable base to go back to, you can try all the changes you want.If you approach the code with a goal, you can then think about likely places where that code would be.
Grep is your friend.
If the code has embedded strings, you can search for those strings.
Otherwise, you can find the handles for those strings, and search for those.
If it is some sort of I/O or database access, search on those call names.
Frequently there are naming conventions that you can learn and use to find stuff.The idea the earlier poster said about putting breakpoints in and/or stepping through the code was right, this is also a very useful practice.
It is much easier to follow the flow if can step through it, especially with C++, where inheritance can often leave one baffled as to which code will actually run.Following main (or your language equivalent) and then drilling down is sometimes useful, but it is often easier to find the bottom and work your way back out.Watchpoints can be really useful.
Find a variable with a value that interests you, and put a watchpoint on it so that it will break when that memory is accessed.
A great way to see which routines are involved.If all else fails, pepper the code with print (or logging) statements and see what shows up.
Try to narrow down what you are looking for.Another useful technique is to comment out a section of code and see where the compile breaks to find dependencies.As you figure stuff out, add comments.
Perhaps also keep a file of notes when you find stuff or figure out how things work.As long as you are focused on solving a particular problem, the code base isn't so unreasonable, because you don't care about most of it.
As you knock down each problem, you learn a little more about the structure of the code.Remember, programming is the art of breaking problems down into smaller problems until they disappear.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125350</id>
	<title>Source browser program is the solution</title>
	<author>Anonymous</author>
	<datestamp>1266053820000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Use a source browser program and you can easily find thing and understanding code written by others in very little time.</p><p>Here there are some links to source browser:<br>http://linguistico.sf.net/wiki/doku.php?id=software\_libero:programmazione#browser\_di\_sorgenti</p></htmltext>
<tokenext>Use a source browser program and you can easily find thing and understanding code written by others in very little time.Here there are some links to source browser : http : //linguistico.sf.net/wiki/doku.php ? id = software \ _libero : programmazione # browser \ _di \ _sorgenti</tokentext>
<sentencetext>Use a source browser program and you can easily find thing and understanding code written by others in very little time.Here there are some links to source browser:http://linguistico.sf.net/wiki/doku.php?id=software\_libero:programmazione#browser\_di\_sorgenti</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122192</id>
	<title>30 to 40 thousand lines isn't large by any measure</title>
	<author>Anonymous</author>
	<datestamp>1265980320000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>0</modscore>
	<htmltext>Yes it's still a bitch to maintain it. But 30k to 40k is by no means large.</htmltext>
<tokenext>Yes it 's still a bitch to maintain it .
But 30k to 40k is by no means large .</tokentext>
<sentencetext>Yes it's still a bitch to maintain it.
But 30k to 40k is by no means large.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123288</id>
	<title>Dear Sir</title>
	<author>nicknamenotavailable</author>
	<datestamp>1265986320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Dear Sir,</p><p>We have recently been placed in charge of inheritance of 40,000 loc, I have the<br>privilege to request your assistance to maintain the henceforth mentioned sum.<br>The above sum resulted from a contract, executed, commissioned and written five<br>years (5) ago by a foreign contractor. This action was however intentional and<br>since then the source has been in a suspended terminal awaiting the fg command.</p><p>We are now ready to transfer the source overseas and that is where you come in.<br>It is important to inform you that as outsourced servants, we are forbidden to<br>debug foreign code; that is why we require your assistance. You will be required<br>to debug and analyze the code and transfer the bug free code to our central<br>repository after which we will reimburse you for your time with post it notes<br>and slightly dated coffee creamer.</p><p>We are looking forward to doing this business with you and solicit absolute<br>confidentiality from you in this transaction. Please acknowledge receipt of<br>this letter, using the above Telefax number for more details regarding this<br>transaction. Also endeavor to send the requested information.</p></htmltext>
<tokenext>Dear Sir,We have recently been placed in charge of inheritance of 40,000 loc , I have theprivilege to request your assistance to maintain the henceforth mentioned sum.The above sum resulted from a contract , executed , commissioned and written fiveyears ( 5 ) ago by a foreign contractor .
This action was however intentional andsince then the source has been in a suspended terminal awaiting the fg command.We are now ready to transfer the source overseas and that is where you come in.It is important to inform you that as outsourced servants , we are forbidden todebug foreign code ; that is why we require your assistance .
You will be requiredto debug and analyze the code and transfer the bug free code to our centralrepository after which we will reimburse you for your time with post it notesand slightly dated coffee creamer.We are looking forward to doing this business with you and solicit absoluteconfidentiality from you in this transaction .
Please acknowledge receipt ofthis letter , using the above Telefax number for more details regarding thistransaction .
Also endeavor to send the requested information .</tokentext>
<sentencetext>Dear Sir,We have recently been placed in charge of inheritance of 40,000 loc, I have theprivilege to request your assistance to maintain the henceforth mentioned sum.The above sum resulted from a contract, executed, commissioned and written fiveyears (5) ago by a foreign contractor.
This action was however intentional andsince then the source has been in a suspended terminal awaiting the fg command.We are now ready to transfer the source overseas and that is where you come in.It is important to inform you that as outsourced servants, we are forbidden todebug foreign code; that is why we require your assistance.
You will be requiredto debug and analyze the code and transfer the bug free code to our centralrepository after which we will reimburse you for your time with post it notesand slightly dated coffee creamer.We are looking forward to doing this business with you and solicit absoluteconfidentiality from you in this transaction.
Please acknowledge receipt ofthis letter, using the above Telefax number for more details regarding thistransaction.
Also endeavor to send the requested information.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31211406</id>
	<title>Use a tool</title>
	<author>Ritchie70</author>
	<datestamp>1266694080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I was unemployed for the first quarter of 2002 and found some by-the-hour contract work maintaining an old Win16 application. Hideous tangle of C code making up a very vertical application.</p><p>I wound up using SciTool's Understand to figure out unwieldy code bases. Honestly I never paid for it, as I said it was a short-term, per-hour contractor job and they weren't paying for tools, so I used the demo until the demo period ran out. (And this wasn't a $200 an hour kind of contract.)</p><p>I've also had Indian consulting firms, as part of their claim that "they can analyze and understand our code base" hand me a report that I'm pretty sure was the output of that product.</p><p>In any case, something like that is a good starting point.</p><p>I guess Visual Studio now has some of that sort of thing built in, but a proper just-for-that tool may suit you better depending on language and style.</p><p><a href="http://www.scitools.com/" title="scitools.com">http://www.scitools.com/</a> [scitools.com]</p></htmltext>
<tokenext>I was unemployed for the first quarter of 2002 and found some by-the-hour contract work maintaining an old Win16 application .
Hideous tangle of C code making up a very vertical application.I wound up using SciTool 's Understand to figure out unwieldy code bases .
Honestly I never paid for it , as I said it was a short-term , per-hour contractor job and they were n't paying for tools , so I used the demo until the demo period ran out .
( And this was n't a $ 200 an hour kind of contract .
) I 've also had Indian consulting firms , as part of their claim that " they can analyze and understand our code base " hand me a report that I 'm pretty sure was the output of that product.In any case , something like that is a good starting point.I guess Visual Studio now has some of that sort of thing built in , but a proper just-for-that tool may suit you better depending on language and style.http : //www.scitools.com/ [ scitools.com ]</tokentext>
<sentencetext>I was unemployed for the first quarter of 2002 and found some by-the-hour contract work maintaining an old Win16 application.
Hideous tangle of C code making up a very vertical application.I wound up using SciTool's Understand to figure out unwieldy code bases.
Honestly I never paid for it, as I said it was a short-term, per-hour contractor job and they weren't paying for tools, so I used the demo until the demo period ran out.
(And this wasn't a $200 an hour kind of contract.
)I've also had Indian consulting firms, as part of their claim that "they can analyze and understand our code base" hand me a report that I'm pretty sure was the output of that product.In any case, something like that is a good starting point.I guess Visual Studio now has some of that sort of thing built in, but a proper just-for-that tool may suit you better depending on language and style.http://www.scitools.com/ [scitools.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127634</id>
	<title>Re:As a maintenance programmer</title>
	<author>DwySteve</author>
	<datestamp>1266081780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Snapshot what you get - don't change it, don't even look at it. As soon as you get it, check it in, binaries and all, to a change tracking system (eg, CVS, SVN, etc).</p></div><p>
This I agree with but for one thing:  Verify that the binaries you are given correspond to the code you are given.  I've seen it too many times where they release a binary, then go back and do 'minor' bug fixes and don't recompile before handing it off to you.<br> <br>
Save the binaries you've been given, then do a clean recompile and compare the two versions as well!</p></div>
	</htmltext>
<tokenext>Snapshot what you get - do n't change it , do n't even look at it .
As soon as you get it , check it in , binaries and all , to a change tracking system ( eg , CVS , SVN , etc ) .
This I agree with but for one thing : Verify that the binaries you are given correspond to the code you are given .
I 've seen it too many times where they release a binary , then go back and do 'minor ' bug fixes and do n't recompile before handing it off to you .
Save the binaries you 've been given , then do a clean recompile and compare the two versions as well !</tokentext>
<sentencetext>Snapshot what you get - don't change it, don't even look at it.
As soon as you get it, check it in, binaries and all, to a change tracking system (eg, CVS, SVN, etc).
This I agree with but for one thing:  Verify that the binaries you are given correspond to the code you are given.
I've seen it too many times where they release a binary, then go back and do 'minor' bug fixes and don't recompile before handing it off to you.
Save the binaries you've been given, then do a clean recompile and compare the two versions as well!
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202</id>
	<title>As a maintenance programmer</title>
	<author>Anonymous</author>
	<datestamp>1265985720000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>As someone who has done probably 90\% of his work in maintenance programming, let me give you my tips:</p><ul><li>Snapshot what you get - don't change it, don't even look at it.  As soon as you get it, check it in, binaries and all, to a change tracking system (eg, CVS, SVN, etc).</li><li>Now that you know what they gave you, and you can get back to it at any time, your options are seemingly limitless, but for the quickest way to get up to speed, I would recommend writing unit tests for the software.  This will be long and tedious, but by writing unit tests you will a) learn what to expect out of the software, b) be able to tell when you break something and c) truly learn the software.</li><li>Automate, automate, automate!  It's a close call as to whether you should start right away on your first unit test, or get the build system automated, but let me just say that it will save you a ton of time to have a "one button push" way to build, run and test the software.  From there, you should be having your machine build and run the unit tests automatically, preferably nightly, from a clean checkout of the repository, just in case you forget to run a test after you change something or you forget to check something in.</li><li>Run the software (including unit tests) through the gauntlet - valgrind's memcheck, electric fence, fuzz, bfbtester, rats, gcc's -fstack-protector-all flag, libc's MALLOC\_CHECK\_=3, gcc's \_FORTIFY\_SOURCE=2 define, gcc's -fmudflap flag, gcc's -Wall -Wextra and -pedantic flags; any way you can think to flush out bugs, do it, and start fixing them; you will learn much, not just about the code, but about the thought process of the original coder(s) this way.  Change tools as appropriate for your programming language and environment (including compiler/interpreter, libs, OS, etc).  As you can tell, I do a lot of C and C++ programming.</li></ul><p>BTW, the fact that you have a hard time understanding this code may be more a reflection on the original authors' coding skills than on your abilities; any idiot can write code that "just works"; it takes a lot of thought, time and effort to write code that is maintainable, and more often than not, the original coders were short on at least one of those (if not all three).  Here's hoping you have the time to follow my above tips; they take a lot of time, but can be worth it if you really need to maintain the code.  It's funny to note that apart from the first one, most of those tips apply equally well to developing software from scratch.  If the code already has a change tracking system, unit tests, a build/run/test system, *and* automated testing, consider yourself lucky and just start picking apart the unit tests.</p></htmltext>
<tokenext>As someone who has done probably 90 \ % of his work in maintenance programming , let me give you my tips : Snapshot what you get - do n't change it , do n't even look at it .
As soon as you get it , check it in , binaries and all , to a change tracking system ( eg , CVS , SVN , etc ) .Now that you know what they gave you , and you can get back to it at any time , your options are seemingly limitless , but for the quickest way to get up to speed , I would recommend writing unit tests for the software .
This will be long and tedious , but by writing unit tests you will a ) learn what to expect out of the software , b ) be able to tell when you break something and c ) truly learn the software.Automate , automate , automate !
It 's a close call as to whether you should start right away on your first unit test , or get the build system automated , but let me just say that it will save you a ton of time to have a " one button push " way to build , run and test the software .
From there , you should be having your machine build and run the unit tests automatically , preferably nightly , from a clean checkout of the repository , just in case you forget to run a test after you change something or you forget to check something in.Run the software ( including unit tests ) through the gauntlet - valgrind 's memcheck , electric fence , fuzz , bfbtester , rats , gcc 's -fstack-protector-all flag , libc 's MALLOC \ _CHECK \ _ = 3 , gcc 's \ _FORTIFY \ _SOURCE = 2 define , gcc 's -fmudflap flag , gcc 's -Wall -Wextra and -pedantic flags ; any way you can think to flush out bugs , do it , and start fixing them ; you will learn much , not just about the code , but about the thought process of the original coder ( s ) this way .
Change tools as appropriate for your programming language and environment ( including compiler/interpreter , libs , OS , etc ) .
As you can tell , I do a lot of C and C + + programming.BTW , the fact that you have a hard time understanding this code may be more a reflection on the original authors ' coding skills than on your abilities ; any idiot can write code that " just works " ; it takes a lot of thought , time and effort to write code that is maintainable , and more often than not , the original coders were short on at least one of those ( if not all three ) .
Here 's hoping you have the time to follow my above tips ; they take a lot of time , but can be worth it if you really need to maintain the code .
It 's funny to note that apart from the first one , most of those tips apply equally well to developing software from scratch .
If the code already has a change tracking system , unit tests , a build/run/test system , * and * automated testing , consider yourself lucky and just start picking apart the unit tests .</tokentext>
<sentencetext>As someone who has done probably 90\% of his work in maintenance programming, let me give you my tips:Snapshot what you get - don't change it, don't even look at it.
As soon as you get it, check it in, binaries and all, to a change tracking system (eg, CVS, SVN, etc).Now that you know what they gave you, and you can get back to it at any time, your options are seemingly limitless, but for the quickest way to get up to speed, I would recommend writing unit tests for the software.
This will be long and tedious, but by writing unit tests you will a) learn what to expect out of the software, b) be able to tell when you break something and c) truly learn the software.Automate, automate, automate!
It's a close call as to whether you should start right away on your first unit test, or get the build system automated, but let me just say that it will save you a ton of time to have a "one button push" way to build, run and test the software.
From there, you should be having your machine build and run the unit tests automatically, preferably nightly, from a clean checkout of the repository, just in case you forget to run a test after you change something or you forget to check something in.Run the software (including unit tests) through the gauntlet - valgrind's memcheck, electric fence, fuzz, bfbtester, rats, gcc's -fstack-protector-all flag, libc's MALLOC\_CHECK\_=3, gcc's \_FORTIFY\_SOURCE=2 define, gcc's -fmudflap flag, gcc's -Wall -Wextra and -pedantic flags; any way you can think to flush out bugs, do it, and start fixing them; you will learn much, not just about the code, but about the thought process of the original coder(s) this way.
Change tools as appropriate for your programming language and environment (including compiler/interpreter, libs, OS, etc).
As you can tell, I do a lot of C and C++ programming.BTW, the fact that you have a hard time understanding this code may be more a reflection on the original authors' coding skills than on your abilities; any idiot can write code that "just works"; it takes a lot of thought, time and effort to write code that is maintainable, and more often than not, the original coders were short on at least one of those (if not all three).
Here's hoping you have the time to follow my above tips; they take a lot of time, but can be worth it if you really need to maintain the code.
It's funny to note that apart from the first one, most of those tips apply equally well to developing software from scratch.
If the code already has a change tracking system, unit tests, a build/run/test system, *and* automated testing, consider yourself lucky and just start picking apart the unit tests.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123796</id>
	<title>Re:Tried and True</title>
	<author>Anonymous</author>
	<datestamp>1265990760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Now that is really poor advice. You better be damn sure the project is salvageable before attempting a rewrite. Otherwise, you can expect the following:</p><p>After you think you understand all of the requirements of your client you'll begin writing code in earnest, only to discover it's going to take way longer than you initially thought. Meanwhile, your client is going to get angry waiting around because to them it doesn't look like any progress is being made. Finally, once you've rewritten 40K lines of code, you have to work the bugs out all over again. In short, that's a lot of wasted time, duplicated effort, and expense for your client.</p><p>Conclusion: if the code works and it serves the clients current needs, then it's worth spending the time to understand it.</p></htmltext>
<tokenext>Now that is really poor advice .
You better be damn sure the project is salvageable before attempting a rewrite .
Otherwise , you can expect the following : After you think you understand all of the requirements of your client you 'll begin writing code in earnest , only to discover it 's going to take way longer than you initially thought .
Meanwhile , your client is going to get angry waiting around because to them it does n't look like any progress is being made .
Finally , once you 've rewritten 40K lines of code , you have to work the bugs out all over again .
In short , that 's a lot of wasted time , duplicated effort , and expense for your client.Conclusion : if the code works and it serves the clients current needs , then it 's worth spending the time to understand it .</tokentext>
<sentencetext>Now that is really poor advice.
You better be damn sure the project is salvageable before attempting a rewrite.
Otherwise, you can expect the following:After you think you understand all of the requirements of your client you'll begin writing code in earnest, only to discover it's going to take way longer than you initially thought.
Meanwhile, your client is going to get angry waiting around because to them it doesn't look like any progress is being made.
Finally, once you've rewritten 40K lines of code, you have to work the bugs out all over again.
In short, that's a lot of wasted time, duplicated effort, and expense for your client.Conclusion: if the code works and it serves the clients current needs, then it's worth spending the time to understand it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123370</id>
	<title>You call *that* large?</title>
	<author>K77</author>
	<datestamp>1265986800000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>I call that a module.  Large is anything over 1,000,000 LOC.  Step up.</htmltext>
<tokenext>I call that a module .
Large is anything over 1,000,000 LOC .
Step up .</tokentext>
<sentencetext>I call that a module.
Large is anything over 1,000,000 LOC.
Step up.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123068</id>
	<title>40,000?!?  ARE YOU KIDDING ME?</title>
	<author>raftpeople</author>
	<datestamp>1265984760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>When I was programming we did every project in 5 lines of code, or less, period.  Anything more than that was just fancy stuff!</htmltext>
<tokenext>When I was programming we did every project in 5 lines of code , or less , period .
Anything more than that was just fancy stuff !</tokentext>
<sentencetext>When I was programming we did every project in 5 lines of code, or less, period.
Anything more than that was just fancy stuff!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31153682</id>
	<title>Re:As a maintenance programmer</title>
	<author>E Jennings</author>
	<datestamp>1266319440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Why has no-one mentioned reverse engineering? Depending on the language used there are tools out there which will analyse the code into UML models. This gives an idea of the architecture; which is always a good starting point. Tools like Rhapsody can round-trip: that is always an interesting experience.</htmltext>
<tokenext>Why has no-one mentioned reverse engineering ?
Depending on the language used there are tools out there which will analyse the code into UML models .
This gives an idea of the architecture ; which is always a good starting point .
Tools like Rhapsody can round-trip : that is always an interesting experience .</tokentext>
<sentencetext>Why has no-one mentioned reverse engineering?
Depending on the language used there are tools out there which will analyse the code into UML models.
This gives an idea of the architecture; which is always a good starting point.
Tools like Rhapsody can round-trip: that is always an interesting experience.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124686</id>
	<title>Write Unit Tests for it</title>
	<author>crispytwo</author>
	<datestamp>1266000120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's a great way to make sure the code works the way you expect, and when it doesn't you can learn how it actually works. Often you will find that this will expose huge flaws in the original code too.<br>After that, it's a source of documentation, sort of.</p><p>Enjoy!</p></htmltext>
<tokenext>It 's a great way to make sure the code works the way you expect , and when it does n't you can learn how it actually works .
Often you will find that this will expose huge flaws in the original code too.After that , it 's a source of documentation , sort of.Enjoy !</tokentext>
<sentencetext>It's a great way to make sure the code works the way you expect, and when it doesn't you can learn how it actually works.
Often you will find that this will expose huge flaws in the original code too.After that, it's a source of documentation, sort of.Enjoy!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122928</id>
	<title>Another "How do I do my job?" ask slashdot. *sigh*</title>
	<author>Anonymous</author>
	<datestamp>1265983980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>And the answer is obvious. UTSL. And since it's now mine anyway, I tend to walk around and see how things work, find places where things don't work so well, and refactor them. It's quite a lot of work, often meaning touching the same code several times to come up with something more modular, more compact, more efficient. Lots of work is ``enabling'' work. Clean up something, see what that exposes or enables some larger change to be put through. After a while change requests become simpler and faster.</p><p>If you want to see how this really works, take projects with lots of fresh graduate or even freshman code in them to poke through. It's not hard, it's just lots of work. But then, what are you being paid for, anyway?</p></htmltext>
<tokenext>And the answer is obvious .
UTSL. And since it 's now mine anyway , I tend to walk around and see how things work , find places where things do n't work so well , and refactor them .
It 's quite a lot of work , often meaning touching the same code several times to come up with something more modular , more compact , more efficient .
Lots of work is ` ` enabling' ' work .
Clean up something , see what that exposes or enables some larger change to be put through .
After a while change requests become simpler and faster.If you want to see how this really works , take projects with lots of fresh graduate or even freshman code in them to poke through .
It 's not hard , it 's just lots of work .
But then , what are you being paid for , anyway ?</tokentext>
<sentencetext>And the answer is obvious.
UTSL. And since it's now mine anyway, I tend to walk around and see how things work, find places where things don't work so well, and refactor them.
It's quite a lot of work, often meaning touching the same code several times to come up with something more modular, more compact, more efficient.
Lots of work is ``enabling'' work.
Clean up something, see what that exposes or enables some larger change to be put through.
After a while change requests become simpler and faster.If you want to see how this really works, take projects with lots of fresh graduate or even freshman code in them to poke through.
It's not hard, it's just lots of work.
But then, what are you being paid for, anyway?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123466</id>
	<title>My Dick is Bigger than Your 250,000 lines of code</title>
	<author>BlueBoxSW.com</author>
	<datestamp>1265987760000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext><p>Really. A guy asks a question for help and all of these people keep telling him 30-40,000 lines of code isn't much.</p><p>That's a lot of code to get your arms around if you didn't write it. It's not the end of the world, but it is a sizeable task, and is the type of topic that few professional journals or books will ever be written about.</p><p>Having been in similar situations, I my advice would be:</p><p>1) Try to get an understanding of the history of the code. Who wrote it? Why? How many developers? How long has it been around? Do people love it or hate it? Is there a version control system in place you can use for information?</p><p>2) Look at it from a technical viewpoint. Is is complete? Does it compile and run? How many languages are used? Are there interfaces with other systems you need to know about? What dependancies are there? How easy is it to setup a test server? What parts are well coded? What parts stink up the joint?</p><p>3) Dig for functional documentation. What does it do? For whom does it do it? What business needs does it support? How mission critical is it?</p><p>4) Meet with the business owners. Seriously. This helps you do two things: #1-- Define the real business need (which may be different than what was understood by the previous developers), and #2-- Set appropriate expectations about maintenance. You'll work hard to maintain and keep it working, but you are working from a disadvantaged position. It is important they know this and support you in your efforts, rather than complain loudly when something doesn't work.</p><p>5) Plan to remove the dead weight. There's always a lot of dead weight in these near-abandonded projects. Get an idea how to simplify things and plan your work in phases.</p><p>6) Setup real test and development servers. Yeah, you know that wasn't already done.</p><p>7) Use version control. But you know this. It's 2010, and no developer worth his/her salt would code a paying project without version control. Right?</p><p>8) All fixes will take much longer than if you wrote the code, so be careful with estimating time.</p></htmltext>
<tokenext>Really .
A guy asks a question for help and all of these people keep telling him 30-40,000 lines of code is n't much.That 's a lot of code to get your arms around if you did n't write it .
It 's not the end of the world , but it is a sizeable task , and is the type of topic that few professional journals or books will ever be written about.Having been in similar situations , I my advice would be : 1 ) Try to get an understanding of the history of the code .
Who wrote it ?
Why ? How many developers ?
How long has it been around ?
Do people love it or hate it ?
Is there a version control system in place you can use for information ? 2 ) Look at it from a technical viewpoint .
Is is complete ?
Does it compile and run ?
How many languages are used ?
Are there interfaces with other systems you need to know about ?
What dependancies are there ?
How easy is it to setup a test server ?
What parts are well coded ?
What parts stink up the joint ? 3 ) Dig for functional documentation .
What does it do ?
For whom does it do it ?
What business needs does it support ?
How mission critical is it ? 4 ) Meet with the business owners .
Seriously. This helps you do two things : # 1-- Define the real business need ( which may be different than what was understood by the previous developers ) , and # 2-- Set appropriate expectations about maintenance .
You 'll work hard to maintain and keep it working , but you are working from a disadvantaged position .
It is important they know this and support you in your efforts , rather than complain loudly when something does n't work.5 ) Plan to remove the dead weight .
There 's always a lot of dead weight in these near-abandonded projects .
Get an idea how to simplify things and plan your work in phases.6 ) Setup real test and development servers .
Yeah , you know that was n't already done.7 ) Use version control .
But you know this .
It 's 2010 , and no developer worth his/her salt would code a paying project without version control .
Right ? 8 ) All fixes will take much longer than if you wrote the code , so be careful with estimating time .</tokentext>
<sentencetext>Really.
A guy asks a question for help and all of these people keep telling him 30-40,000 lines of code isn't much.That's a lot of code to get your arms around if you didn't write it.
It's not the end of the world, but it is a sizeable task, and is the type of topic that few professional journals or books will ever be written about.Having been in similar situations, I my advice would be:1) Try to get an understanding of the history of the code.
Who wrote it?
Why? How many developers?
How long has it been around?
Do people love it or hate it?
Is there a version control system in place you can use for information?2) Look at it from a technical viewpoint.
Is is complete?
Does it compile and run?
How many languages are used?
Are there interfaces with other systems you need to know about?
What dependancies are there?
How easy is it to setup a test server?
What parts are well coded?
What parts stink up the joint?3) Dig for functional documentation.
What does it do?
For whom does it do it?
What business needs does it support?
How mission critical is it?4) Meet with the business owners.
Seriously. This helps you do two things: #1-- Define the real business need (which may be different than what was understood by the previous developers), and #2-- Set appropriate expectations about maintenance.
You'll work hard to maintain and keep it working, but you are working from a disadvantaged position.
It is important they know this and support you in your efforts, rather than complain loudly when something doesn't work.5) Plan to remove the dead weight.
There's always a lot of dead weight in these near-abandonded projects.
Get an idea how to simplify things and plan your work in phases.6) Setup real test and development servers.
Yeah, you know that wasn't already done.7) Use version control.
But you know this.
It's 2010, and no developer worth his/her salt would code a paying project without version control.
Right?8) All fixes will take much longer than if you wrote the code, so be careful with estimating time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31145342</id>
	<title>Reverse Engineer to UML class diagrams</title>
	<author>Anonymous</author>
	<datestamp>1266255540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>And once you're done with that, create UML sequence diagrams of various use cases. Make sure to use a debugger to create the sequence diagrams. After you're done, you'll know parts of the code better than the original authors.</p><p>Have fun and good luck!!</p></htmltext>
<tokenext>And once you 're done with that , create UML sequence diagrams of various use cases .
Make sure to use a debugger to create the sequence diagrams .
After you 're done , you 'll know parts of the code better than the original authors.Have fun and good luck !
!</tokentext>
<sentencetext>And once you're done with that, create UML sequence diagrams of various use cases.
Make sure to use a debugger to create the sequence diagrams.
After you're done, you'll know parts of the code better than the original authors.Have fun and good luck!
!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124696</id>
	<title>Not many people do this</title>
	<author>symbolset</author>
	<datestamp>1266000240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>More should.  It's a small part of the problem, but it does help.</htmltext>
<tokenext>More should .
It 's a small part of the problem , but it does help .</tokentext>
<sentencetext>More should.
It's a small part of the problem, but it does help.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123380</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125466</id>
	<title>Re:Use it</title>
	<author>gknoy</author>
	<datestamp>1266056400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I find it especially handy when you need to debug (or just report on) or test the parts of an equation.  My giant multi-term formula is Failing Somehow<nobr> <wbr></nobr>... why? is it bad input? Which sub-term is nil? Am I even implementing the formula correctly?  Intermediate named variables really help with this.</p></htmltext>
<tokenext>I find it especially handy when you need to debug ( or just report on ) or test the parts of an equation .
My giant multi-term formula is Failing Somehow ... why ? is it bad input ?
Which sub-term is nil ?
Am I even implementing the formula correctly ?
Intermediate named variables really help with this .</tokentext>
<sentencetext>I find it especially handy when you need to debug (or just report on) or test the parts of an equation.
My giant multi-term formula is Failing Somehow ... why? is it bad input?
Which sub-term is nil?
Am I even implementing the formula correctly?
Intermediate named variables really help with this.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123230</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127878</id>
	<title>Start at the Beginning</title>
	<author>frankj2k10</author>
	<datestamp>1266083760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I haven't read through all the posts and there are some great suggestions and strategies that have been outlined.
<br>
I've been through the same situation quite a few times in my career.
<br> <br>
Have you been able to track down any of the project artifacts developed as the software was being created.
<br>
Business requirements, functional requirements, use cases, design docs, database designs, user guides, etc.
<br> <br>
I know these documents, if they exist, can be out of date, incomplete, or puzzle pieces for how the software has evolved over time.
<br>
However, what may exist might be able to provide a high level picture of the software from different perspectives and shed some light on little nuances.</htmltext>
<tokenext>I have n't read through all the posts and there are some great suggestions and strategies that have been outlined .
I 've been through the same situation quite a few times in my career .
Have you been able to track down any of the project artifacts developed as the software was being created .
Business requirements , functional requirements , use cases , design docs , database designs , user guides , etc .
I know these documents , if they exist , can be out of date , incomplete , or puzzle pieces for how the software has evolved over time .
However , what may exist might be able to provide a high level picture of the software from different perspectives and shed some light on little nuances .</tokentext>
<sentencetext>I haven't read through all the posts and there are some great suggestions and strategies that have been outlined.
I've been through the same situation quite a few times in my career.
Have you been able to track down any of the project artifacts developed as the software was being created.
Business requirements, functional requirements, use cases, design docs, database designs, user guides, etc.
I know these documents, if they exist, can be out of date, incomplete, or puzzle pieces for how the software has evolved over time.
However, what may exist might be able to provide a high level picture of the software from different perspectives and shed some light on little nuances.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126180</id>
	<title>Re:Not at all.</title>
	<author>Anonymous</author>
	<datestamp>1266069000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><blockquote><div><p>I find that if the other programmer wrote it in such a way where it's too complex for me to follow, I'm not the one who's a moron.</p></div></blockquote><p>How exciting and different that must be for you.</p></div>
	</htmltext>
<tokenext>I find that if the other programmer wrote it in such a way where it 's too complex for me to follow , I 'm not the one who 's a moron.How exciting and different that must be for you .</tokentext>
<sentencetext>I find that if the other programmer wrote it in such a way where it's too complex for me to follow, I'm not the one who's a moron.How exciting and different that must be for you.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122286</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122702</id>
	<title>Hunt down the original developer(s)</title>
	<author>Anonymous</author>
	<datestamp>1265982600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><blockquote><div><p>(And then shoot <b>them</b>.)</p></div></blockquote><p>Good lord, you're not going to eat'em afterward, are you?</p></div>
	</htmltext>
<tokenext>( And then shoot them .
) Good lord , you 're not going to eat'em afterward , are you ?</tokentext>
<sentencetext>(And then shoot them.
)Good lord, you're not going to eat'em afterward, are you?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122276</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124452</id>
	<title>Re:Not lots of code</title>
	<author>jhol13</author>
	<datestamp>1265997360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You mean "Exuberant Ctags", don't you?</p></htmltext>
<tokenext>You mean " Exuberant Ctags " , do n't you ?</tokentext>
<sentencetext>You mean "Exuberant Ctags", don't you?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127602</id>
	<title>tests</title>
	<author>bytesex</author>
	<datestamp>1266081600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You find out what it's supposed to do according to functional spec, and you write a test-suite against it.  Two birds with one stone.</p></htmltext>
<tokenext>You find out what it 's supposed to do according to functional spec , and you write a test-suite against it .
Two birds with one stone .</tokentext>
<sentencetext>You find out what it's supposed to do according to functional spec, and you write a test-suite against it.
Two birds with one stone.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122946</id>
	<title>Re:Hunt down the original developer</title>
	<author>Anonymous</author>
	<datestamp>1265984100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>(And then shoot him.)</p></div><p>Well, he inherited the code. Which means someone died and left it to him. So, he'd be shooting a dead person. </p><p>What's the point?</p><p>Contest the will?</p></div>
	</htmltext>
<tokenext>( And then shoot him .
) Well , he inherited the code .
Which means someone died and left it to him .
So , he 'd be shooting a dead person .
What 's the point ? Contest the will ?</tokentext>
<sentencetext>(And then shoot him.
)Well, he inherited the code.
Which means someone died and left it to him.
So, he'd be shooting a dead person.
What's the point?Contest the will?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122276</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127888</id>
	<title>Re:Not lots of code</title>
	<author>oldhack</author>
	<datestamp>1266083820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>You see that dog?  That's my dog crapping in your lawn.</htmltext>
<tokenext>You see that dog ?
That 's my dog crapping in your lawn .</tokentext>
<sentencetext>You see that dog?
That's my dog crapping in your lawn.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125540</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31133834
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125868
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123314
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_56</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122710
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126370
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122782
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122842
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31135852
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123796
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125074
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128562
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125290
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124348
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123616
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31141246
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_68</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125410
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123300
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123420
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123434
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126274
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31131706
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125234
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_65</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127634
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122354
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126612
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123230
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125466
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122286
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124476
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122256
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123468
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_55</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128006
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125300
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123466
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125580
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125802
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123068
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125698
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124370
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31153682
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123138
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_63</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122286
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122886
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_54</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126624
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123524
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123616
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124248
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127646
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125880
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122256
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126414
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122276
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122702
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128880
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124526
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_69</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125540
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31133152
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31135910
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122286
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125252
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122256
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123000
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_59</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122256
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127196
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123616
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128392
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124354
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123466
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124614
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127800
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123272
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_66</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122286
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126180
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122192
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122440
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125808
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123380
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124696
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126386
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_67</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122256
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123054
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_58</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123866
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126580
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125540
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127888
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_61</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128240
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124452
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_57</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126356
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123866
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127336
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_60</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124428
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_62</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123466
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125044
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_64</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123230
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128466
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124536
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_12_2329252_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122276
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122946
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122314
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123616
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31141246
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128392
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124248
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127646
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124348
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124536
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122782
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123230
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125466
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128466
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31131706
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122710
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126370
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125880
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123434
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122290
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122356
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123300
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123796
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125378
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125808
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125290
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31135910
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123138
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127602
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128228
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123866
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126580
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127336
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123202
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124370
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124354
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125074
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31153682
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127634
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128562
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126274
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128006
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122286
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126180
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125252
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122886
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124476
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122192
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122440
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123466
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125580
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125044
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124614
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122256
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123000
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123468
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126414
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123054
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127196
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123380
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124696
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124686
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31137334
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122354
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126612
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122846
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125410
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123524
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125868
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123420
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125300
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31133834
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124526
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122404
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122414
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122476
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122276
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122702
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122946
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125078
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123940
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122260
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128880
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127800
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124452
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31128240
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125540
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31133152
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31127888
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126386
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123272
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125234
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123314
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31124428
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126356
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31135852
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31126624
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125802
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31122842
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_12_2329252.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31123068
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_12_2329252.31125698
</commentlist>
</conversation>
