Slashdot Mirror

The source code is the blueprint/architectural plan/schematic.

The incoherent ramblings of marketing/sales/etc and the software specifications are the equivalent of the initial meeting with the architect saying we want 20 stories and a south-facing balcony on each external wall.

Three Essays by Jack W Reeves.
The Source Code Is The Design.

Yes it is. It refers to the "WikiWikiWeb" at c2.com. This was the first wiki ever made, by the way.

I never said anything about what I was in favour of. Pointing to a set of artificial numbers doesn't really help, either; for 99% of cases they're irrelevent past a point most languages reach with ease (and by those numbers, a language with somewhat nicer looking semantics than C/++ seems to be winning); where they are relevent, dipping into a lower level language just for that is normally a better choice than doing your entire app in C. Alternate hard and soft layers. Plenty of systems, including games, follow this pattern.

Yes, IT's not easy, but most of the real complexity is in the data and the algorithms you use; adding more complexity to everything by using a basic very low level language for the sake of performance you normally don't need is just silly. Frankly, even when performance is needed, languages like C/++ are often still too low level -- you should be able to trade off less in the way of programmer friendliness without removing significant chunks of performance. But now I'm handwaving :P

There Is Historical Precedent For This.

(Unfortunately, that doesn't make it any less annoying...)

XP, arguably the 600 pound gorilla of the "agile methodologies," was created by Kent Beck, Ward Cunningham, and Ron Jeffries. It was a direct outgrowth of their work the "Chrysler Comprehensive Compensation (C3) System," and information about their brand new methodology was publicized on a little web site Cunningham had put together.

It just so happened that the "little web site" was the very first Wiki. One of the side effects here is that since each of the XP principles got its own page, it also got its VeryOwnNameInCamelCase. The weird capitalization of the rules is an artifact of agile methodologies' debt to the wiki format.

Or something. I think.

http://www.c2.com/cgi/wiki?CategoryVoting

About percents adding up to 100%:

http://www.c2.com/cgi/wiki?JustMakeItRight

As with any other method, it assumes all the specs and implementation have been worked out before the code is even written...

Completely untrue. See Spike Solution, for example.

its amazing how most new features are always rated as low priority by someone other than the customer....even more amazing about how many 'stories' aren't written by the customer

It is. What you describe isn't XP. It doesn't surprise me that it didn't work very well.

Some time ago i posted the following on a wiki
http://c2.com/cgi/wiki?HowToImprovePatents

# The evaluation of patents should be based on objective methods, not subjective rules.

# A business secret rule. To get a patent on an idea it most be a business secret. an idea is a business secret if it can be used in a business without giving it away. An contra example is amazons one click patent which can't be used in business without reveling it. This rule insure that the community get something in exchange for the patent monopoly.

# A bounty system. The patent systems should be a public bounty system. Every patent application should have a bounty on it. The initial bounty is payed by the patent seeker but it should be possible for others to add to a bounty.

# Internet system: The patents examination should be made public on the Internet where it should be accessible to all without cost.

# Non-obvious tests: First the technical problem should be posted and the should be a period for the public to post solutions to the problem, if the solution is posted. Then the poster get the bounty and the patent is rejected as obvious. But the posted solution remains available to the public.

# Novelty test: Then the patent solutions is posted and the should be a period to find prior art. If prior art is found the patent fails the novelty test and the finder get the bounty.

IN HONOR OF THE SUBJECT MATERIAL, I HAVE CHOSEN TO USE THE CAPS LOCK FOR THE FIRST TIME IN MY LIFE FOR THIS POST.

On second thought, that's far too annoying.

If the proposed abolishment of caps lock keys is successful, I grow concerned about what myself and my predecessors will celebrate on INTERNATIONAL CAPS LOCK DAY which happens to be October 22. And don't tell me it's not a real holiday because that is one convincing website. It has a news flash with a picture of a potato, uses the word "bitches" and has a countdown for the days remaining to INTERNATIONAL CAPS LOCK DAY. And look at this other reputable site, Out House Rag that also backs INTERNATIONAL CAPS LOCK DAY. That's more than Adults Day in Japan has to say! Please, if I have to put up with one more Nevada Day (October 31) the least you can do is let me have my INTERNATIONAL CAPS LOCK DAY. Please don't remove your caps lock key because they're not evil!

You know, there's this horrible site that actually encourages you to remap your caps lock to a more suitable function ... but of course that would just be sacrilegious and a very dangerous process (don't try it at home!).

XML is often poorly normalized such that you have to go out of your way to remove nesting, redundancies, etc. Why not clean up comma-delimited a bit so that it offers better meta-data (column types, etc.) and multi-schemas per file. Comma-delimited is also more compact. For some ideas, see:

http://www.c2.com/cgi/wiki?RelationalAlternativeTo Xml

I have found that companies generally don't seem to value domain (biz) knowledge, and others seem to agree. Here is more on this phenom:

http://www.c2.com/cgi/wiki?WhyIsDomainKnowledgeNot Valued

It only sounds like that if you skip the important parts.

Agile methods are not about skipping requirements, or modeling, nor about coding in a casual or non-deliberate way.

Agile methods are about recognizing that requirements are a moving target, That the more you implement your solution, the better you will understand the model, and possible problems with your model of the problem domain, and that the best program on earth is worthless if it doesn't work for the end users.

So, there's a large collection of techniques that most programming veterans (OO or otherwise) utilize to help get things up and running without having to send anyone "over the waterfall."

Check out Dave Thomas and Andy Hunt, Martin Fowleror the Portland Pattern Repository for a good starting point.

The bicycle analogy simply isn't the same thing. I've yet to find a web site which lists spots you can go to find free bicycles to ride.

This is where you are wrong. Portland (the city in this article) used to offer free bicycles -- yellow ones to be exact -- that could be used temporarily. The problem was people started stealing them. Guess that analogy works perfectly now, eh?

Yellow Bike Project

While having tools to assist in the actual task of navigating through the codebase is important, a firm handle on the HOW is more critical.

http://c2.com/cgi/wiki?TipsForReadingCode
"Comprehension and Visualisation of Object-Oriented Code for Inspections" http://www.cis.strath.ac.uk/research/efocs/abstrac ts.html#EFoCS-33-98 section 5.
Demeyer, Serge. Ducasse, Stephane. Nierstrasz, Oscar. Object Oriented Reengineering Patterns ISBN: 1558606394
Feathers, Michael. Working Effectively with Legacy Code ISBN: 0131177052
Glass, Robert L. Facts and Fallacies of Software Engineering, section in Chapter 2 on Maintenance ISBN: 0321117425
Spinellis, Diomidis. Code Reading: The Open Source Perspective ISBN: 0201799405

it's fugly. i hate fugliness!

Others have made similar observations to mine:

http://c2.com/cgi/wiki?WhyIsDomainKnowledgeNotValu ed

I recall the palpable buzz at the an Apple developer conference (Canberra? The year I read Jonno's copy of Vernor Vinge's The Peace War(?) during the long drive from Melbourne) where illicit copies of Silver Surfer -- pre-release HyperCard -- were being smuggled on to developers' systems and whispered about. Believe me, almost everyone who saw it -- five years before Berners-Lee kicked off the WWW on his NeXT -- recognised how exciting a paradigm it defined. Including Apple! On the Mac, for high level application developers, this was the era of Helix (exciting) and OMNIS (not very). (Confession: I think I was too young to entirely get what the fuss was all about.)

In those eight years before the web took firm hold, HyperCard was constantly promoted and bundled in very visible form (including printed manuals) with every Macintosh sold. It had a plugin architecture, and a massive roster of third party developers and solutions. My brother built an accounting system for a family business with it.

As a more bare-metal C/Pascal Mac developer during this period, I sometimes grew exasperated at the ubiquity of this seemingly pedestrian product I wasn't much interested in using!

I recall the palpable buzz at the an Apple developer conference (Canberra? The year I read Jonno's copy of Vernor Vinge's The Peace War(?) during the long drive from Melbourne) where illicit copies of Silver Surfer -- pre-release HyperCard -- were being smuggled on to developers' systems and whispered about. Believe me, almost everyone who saw it -- five years before Berners-Lee kicked off the WWW on his NeXT -- recognised how exciting a paradigm it defined. Including Apple! On the Mac, for high level application developers, this was the era of Helix (exciting) and OMNIS (not very). (Confession: I think I was too young to entirely get what the fuss was all about.)

In those eight years before the web took firm hold, HyperCard was constantly promoted and bundled in very visible form (including printed manuals) with every Macintosh sold. It had a plugin architecture, and a massive roster of third party developers and solutions. My brother built an accounting system for a family business with it.

As a more bare-metal C/Pascal Mac developer during this period, I sometimes grew exasperated at the ubiquity of this seemingly pedestrian product I wasn't much interested in using!

Ghost of Usenet Postings Past.

> it just won't be in America. Countries like China, and to a lesser
> extent India, will soon become the hubs

Bah. China has got its own set of problems, for example, they're busy limiting the names of newborn babies.

And if by "religious fundamentalists" you mean people like Donald Knuth and John Vlissides, I think we're doing OK.

There's a reason they are called Smug Lisp Weenies.

Don't worry though. The AC is just parroting crap he's seen on the net and has never done anything meaningful in Lisp.

If Lisp was the greatest thing since sliced bread it would have gained more acceptance. Or maybe the smug lisp weenies are busy wanking on how great their language is instead of actually producing stuff - like RoR.

> sanity checking, authorization, the SQL the page needs and nothing more,

Don't repeat yourself:
http://c2.com/cgi/wiki?DontRepeatYourself

k2r

FogBugz is great. Sure, it's a commercial system that you have to pay for, but it is easy to install, simple to use, has a very clean user interface and even has a philosophy. Believe it or not, the last point is the most important. The folks behind FogBugz seem to work really hard to adhere to the KISS pricipal and produce a superior product.

If you compare them to workhorses like Bugzilla, Fogbugz seems very minimalistic, but it turns out to actually be more useful that way. The guy behind the folks behind Fogbugz, Joel Spolsky, has lots of interesting things to say about the design of Fogbugz that are just good reading for ANY CS/IT person to even if you don't buy his product.

Another product that I tried out was scarab, which was appealing since it was a Java J2EE application from the same folks who brough us subversion. From a CS point of view, scarab is an interesting example of how to use turbine. Unfortunately, scarab is hard to install and configure.

Although the version of scarab that I tested was still a beta product that might not be quite so hard to use out of the box any more, it is interesting to compare it to FogBugz. Scarab had the kitchen sink approach that is so configurable that it could be set up to be every bit as complicated as Bugzilla or as simple as FogBugz. However this flexibility made it a nightmare to configure and administer. While you could, conceivably set it up like FogBugz, it would be hard to make it work exactly the same way and wouldn't provide the same ease of use... just the same limitations with an added level of complexity.

To summarize less is more... in quality and price this time ;)

Long before Trac for Subversion, there was CVSTrac for CVS. It's a little more austere, but offers the same features: integrated wiki, CVS change tracker, CVS browser, and trouble tickets. CVSTrac now can be compiled to support Subversion.

FitNesse combines a Wiki with an acceptance testing tool. Tables on Wiki pages hold test data and expected outputs; click the "test" button and FitNesse runs your application with the test data and checks the results against the expected values (similar to JUnit and others). Although written in Java, FitNesse also can test Python, Ruby, C++, .NET, Smalltalk, and Perl applications. FitNesse builds on Fit, the Framework for Integrated Testing by Ward Cunningham, the creator of the original Wiki.

Ward also was the first person to integrate source code into a Wiki. In his WikiBase , Ward presents the source code for his original Wiki on Wiki pages containing HyperPerl, a Perl implementation of Literate Programming. This may not suit current development needs, but it is fascinating.

Long before Trac for Subversion, there was CVSTrac for CVS. It's a little more austere, but offers the same features: integrated wiki, CVS change tracker, CVS browser, and trouble tickets. CVSTrac now can be compiled to support Subversion.

FitNesse combines a Wiki with an acceptance testing tool. Tables on Wiki pages hold test data and expected outputs; click the "test" button and FitNesse runs your application with the test data and checks the results against the expected values (similar to JUnit and others). Although written in Java, FitNesse also can test Python, Ruby, C++, .NET, Smalltalk, and Perl applications. FitNesse builds on Fit, the Framework for Integrated Testing by Ward Cunningham, the creator of the original Wiki.

Ward also was the first person to integrate source code into a Wiki. In his WikiBase , Ward presents the source code for his original Wiki on Wiki pages containing HyperPerl, a Perl implementation of Literate Programming. This may not suit current development needs, but it is fascinating.

Long before Trac for Subversion, there was CVSTrac for CVS. It's a little more austere, but offers the same features: integrated wiki, CVS change tracker, CVS browser, and trouble tickets. CVSTrac now can be compiled to support Subversion.

FitNesse combines a Wiki with an acceptance testing tool. Tables on Wiki pages hold test data and expected outputs; click the "test" button and FitNesse runs your application with the test data and checks the results against the expected values (similar to JUnit and others). Although written in Java, FitNesse also can test Python, Ruby, C++, .NET, Smalltalk, and Perl applications. FitNesse builds on Fit, the Framework for Integrated Testing by Ward Cunningham, the creator of the original Wiki.

Ward also was the first person to integrate source code into a Wiki. In his WikiBase , Ward presents the source code for his original Wiki on Wiki pages containing HyperPerl, a Perl implementation of Literate Programming. This may not suit current development needs, but it is fascinating.

Long before Trac for Subversion, there was CVSTrac for CVS. It's a little more austere, but offers the same features: integrated wiki, CVS change tracker, CVS browser, and trouble tickets. CVSTrac now can be compiled to support Subversion.

FitNesse combines a Wiki with an acceptance testing tool. Tables on Wiki pages hold test data and expected outputs; click the "test" button and FitNesse runs your application with the test data and checks the results against the expected values (similar to JUnit and others). Although written in Java, FitNesse also can test Python, Ruby, C++, .NET, Smalltalk, and Perl applications. FitNesse builds on Fit, the Framework for Integrated Testing by Ward Cunningham, the creator of the original Wiki.

Ward also was the first person to integrate source code into a Wiki. In his WikiBase , Ward presents the source code for his original Wiki on Wiki pages containing HyperPerl, a Perl implementation of Literate Programming. This may not suit current development needs, but it is fascinating.

Long before Trac for Subversion, there was CVSTrac for CVS. It's a little more austere, but offers the same features: integrated wiki, CVS change tracker, CVS browser, and trouble tickets. CVSTrac now can be compiled to support Subversion.

FitNesse combines a Wiki with an acceptance testing tool. Tables on Wiki pages hold test data and expected outputs; click the "test" button and FitNesse runs your application with the test data and checks the results against the expected values (similar to JUnit and others). Although written in Java, FitNesse also can test Python, Ruby, C++, .NET, Smalltalk, and Perl applications. FitNesse builds on Fit, the Framework for Integrated Testing by Ward Cunningham, the creator of the original Wiki.

Ward also was the first person to integrate source code into a Wiki. In his WikiBase , Ward presents the source code for his original Wiki on Wiki pages containing HyperPerl, a Perl implementation of Literate Programming. This may not suit current development needs, but it is fascinating.

Sounds like what is really needed is an implementation of "Dynamic Relational":

http://www.c2.com/cgi/wiki?DynamicRelational

• Wiki pages represent consensus because it's much easier to delete insults and remove WikiSpam than indulge them. What remains is naturally meaningful and has been essentially collated from multiple points of view.
• To make an impact on Wiki, you need to generate real content. Anything else will be removed. So anyone can play, but only good players remain.

"Anyone can edit it... [but] why would I? Why would anyone waste their time?"

Here is a list of testing frameworks for several languages.

http://c2.com/cgi/wiki?TestingFramework

G.

This reminds me of a page I started at Ward's Wiki:

Computer ProgrammingLanguages are only a subset of the different languages found on Earth. All languages from the most simplistic odors and back-archings to the most complicated multi-lingual pattern labyrinths are used to convey information and direct the actions of others. In order to be effective at communicating and directing actions in a complex world, many different languages must be employed. As soon as one's baby brain realizes how to use sounds and body language to get someone to do something, one becomes a programmer. While a child is a considerable novice to programming, an effective politician or entertainer is a master programmer. It's as simple as getting food and as complex as controlling the populations of several countries.

http://www.c2.com/cgi/wiki/wiki?AllLanguageIsProgr amming

if you then treat wiki edits as change requests to be reviewed and prioritized (i.e. moderated), you'd have a rather useful tool for communications between business requirements, implementation, deployment, and support teams.

Battle of Wits

I like Wikipedia but I thought Wiki were made famous by c2.com.

Look here.

Will someone with a really innovative idea open source it from the beginning?

• Freenet
• The World Wide Web: both the Web server...
• ... and of course the Web Browser, too.
• Up to the moment, there's Wiki
• And if you go back far enough in history, there's that computerised psychoanalyst that's generally not used exceptby middle aged computer scientists. I can't remember it's name, but it has a built in editor, too.

So nothing very significant, no.

FYI, I'm not latching onto or regurgitating someone else's complaints as if they're my own -- I wrote that chapter in the Unix Haters handbook, based on years of experience with X. I attended the original X conference at MIT, and I've been using X since X10, ported SimCity to X11, developed a multi player user interface for SimCity that supported multiple servers connected to the same X11 client, and sold multiplayer SimCity as a commercial product in 1992. So I think I have the right to complain about the shortcomings of X, without being accused of regurgitating someone else's opinion.

Here's some nifty X10 window manager code I wrote in Forth in 1986:

X.f - X10 window system interface for Forth.
Xlib.f - X10 XLib interface for Forth.
xutil.f - X10 utilities for Forth.
uwm.f - X10 uwm window manager interface for Forth.
load-fuwm.f - X10 uwm library loader for Forth window manager.
fuwm-main.f - X10 Forth window manager main driver.
menulist.f - pie menus and linear menus for Forth window manager. hacks.f - X10 Forth window manager hacks.

I extended Gancarz's original X10 "uwm" window manager in C to support pie menus, then I broke it up into a library so I could link it into Mitch Bradley's Sun Forth (Forthmacs) and script it in Forth. We used it to perform an experiment comparing pie menus and linear menus. (Pie menus won hand down!)

The last file (hacks.f) is especially fun, because it lets you pick up windows and fling them around the screen, so any number of windows will bounce around on the screen with inertia and gravity and friction, each with their own Forth task. It ran quite fast on a 4 meg Sun 3/50, with enough room for Emacs to bounce around too.

Programming a window manager with a stack based language foreshadowed the work I later did with the NeWS window system and user interface toolkit, which is an extensible window system written by James Gosling, scripted in PostScript.

Ever heard of AJAX? NeWS did cool stuff that X still can't touch 20 years later, like dynamically downloading code to the server to define efficient application specific protocols and implememt locally interactive custom user interfaces. AJAX is not a new idea, and it wasn't even invented by Microsoft: NeWS was totally "AJAXian" 20 years ago, but with PostScript code instead of JavaScript, PostScript graphics instead of HTML, and PostScript data instead of XML -- much more consistent and easier to program than AJAX's potpourri of incompatible standards!

Believe it or not: with NeWS, you could actually draw circles and diagonal lines in PostScript without making a remote procedure call to download an image (like Google Maps has to do, in order to support Firefox).

-Don

On the other hand, you might want to Forget the debugger.

In contrast, WardsWiki has a list of how to make it so your code doesn't need comments so often: SelfDocumentingCode

All of the reasons given for manual memory management seem to boil down to a desire to have support for the Resource Acquisition Is Initialization (RAII) idiom, which is hard to pull off in GC languages. But, the alternative idiom Resource Acquisition Is Invocation provides the desired capability in GC languages. Same capability, no chance of memory leaks. So tell me again why manual memory management might be a good idea?

When you hear Ruby in the context of web applications, the speaker definitely means Ruby on Rails. For writing more than the simplest web application, it's probably a php killer, on account of its price ($0) and relatively flat learning curve (even if you've never done ruby). Others have observed that RoR has subtle ways of making you do the right thing in a given programming situation, even if you don't know what that is at the time. I dare say that rails teaches the coder alot about object-oriented programming just by using it.

RoR is just 1.0 now, and though the API is still shifting around a bit, it does so only about as much as php, and rails is just a framework, not the whole language. The ruby language itself is quite stable at this point. OTOH, I found that porting my existing web app over to RoR was impossible, or at least so difficult that it wasn't worth the trouble over re-coding it from scratch (and making it a much better app in the process).

Most people who advance coding standards talk about how braces should be put and whether there should be used braces in one-line if's, maybe they even mention the horrible and feared Hungarian Notation. I have yet to find out how any of this *actually* helps understanding code.

Readable code is a prerequisite for understandable code, education is a prerequisite for understanding.

Coding-standards is trying to apply a method of syntax to an education-problem, it's not gonna work. Don't think that coding-standards will give you readability, much less understanding.

My advice is to get a few people with experience, solid, broad knowledge of the language and a pragmatic attitude to sit down and pair-program with the people who write hard-to-understand code and those who have a hard time understanding code that should have been easy to understand.

Let people present idioms, discuss patterns and create a place where "readability" is a code-quality and a goal. (BTW: Don't fall into the "everthing is a pattern"-trap) This is not a coding standard, it's an education of "this-way-works-well-for-this-and-that".

Promote knowledge of the language standard-library, instead of duplicating it yourself. Learn to shun "wrappers". Use the language-features for what they were meant to do, not for insert-really-cunning-hack-here. Model things as they are, instead of cutting coreners or adding complexity.

Check out c2.com http://c2.com/cgi/wiki?WelcomeVisitors it's really a place worth knowing. Read the dialogs, they may not all be truly insightfull but they provide you with excellent examples of what people think about in development and why it's not that easy to do-the-right-thing.

One specific thing i've found is that most people write code by copying (atleast a skeleton) from somewhere else. Accept this, and to give them something *proper* to copy from, short, complete programs -- taken from real situations, Not crappy code-project articles where people try to show off how complicated a technique they can master.

If a company hires good programmers the one doing the typing does almost all the work while the other person tries desperately to keep awake

Wrong. If "the other person tries desperately to stay awake" then they're not doing their job. The keyboardist's goal is to make write the next method that will make the current test pass. Because of this narrow, simple focus, the person away from the keyboard is *not* a passive observer and in fact has several duties and responsibilities:

1) Reviewing the code as the other person types - for typos, semantic defects, and possible improvements and alternatives.
2) Reviewing the overall design of the class
3) Considering the next unit test
4) Managing the goal stack
5) Asking questions when the intention of the code is not clear (to the non-keyboardist)

If the non-keyboardist is getting bored, then she's not accepting co-responsibility for the code she and her partner are creating. This is not being a good programmer.

Take a look at one of the Agile Poster Children and his proof that it works.

Quote: "Because of the newness of agile methods there simply hasn't been sufficient time to prove that they work in a wide variety of situations."

Thats a wonderful way to dismiss anyone saying bad things, and it's rubbish, because the burden of proof for any claim is independent of its age.

Quote: "the question "where is the proof" is typically asked by organizations that fit the late majority or even laggard profiles ... Because agile techniques clearly aren't at that stage in their lifecycle yet I believe that this question simply isn't a fair one at this time."

So the act of asking for proof these things work means you're not ready? Ad hominem alert.

Quote: "Are they really interested in finding an effective process or are [they] merely looking for a reason to disparage an approach that they aren't comfortable with? Are they realistic enough to recognize that no software process is perfect, that there is no silver bullet to be found? Are they really interested in proof that something works, or simply an assurance of perceived safety?"

Ad hominem again.

Then you look at the project that started Agile, the Chrysler Comprehensive Compensation (C3) project. It was lauded as the first agile program and a success, however by February 2000 with the system was failing when paying 76,000 of the company's 86,000 employees. It was cancelled. Apparently this failure is now the new success.

Every methodology has rapid followers who will hear not evil said of it, but when looking at these things you have to remember "He's NOT the Messiah ... he's just a very naughty boy."

At the C2 wiki some of us have been thinking about this question for years. Here are some key topics on it, including my pet SQL replacement suggestion:

http://www.c2.com/cgi/wiki?SqlFlaws

http://www.c2.com/cgi/wiki?TqlRoadmap

At the C2 wiki some of us have been thinking about this question for years. Here are some key topics on it, including my pet SQL replacement suggestion:

http://www.c2.com/cgi/wiki?SqlFlaws

http://www.c2.com/cgi/wiki?TqlRoadmap

...I'd say here:

http://mindview.net/Books

and here:

http://www.c2.com/cgi/wiki?WelcomeVisitors

and maybe here:

http://www.objectmentor.com/resources/articleIndex

And although a lot of people around here would probably disagree, I think it would be worth your time to go back and try to get a Computer Science degree. Programming != Computer Science, but it's helpful to understand the scientific principles that modern software development is based on.

Note he didn't start Wikipedia, he came up with the idea of wiki. Ward's Wiki is the Portland Pattern repository which is always a very educational read for software practitioners.

I applaud your professor or thesis advisor or whoever for this real-world task. Here's a few resources which I wouldn't do without:
Code Reading: The Open Source Perspective
Object-Oriented Reengineering Patterns
Reading Computer Programs: Instructor's Guide and Exercise
Tips for Reading Code