Dispatches from Andyland

My mom is normally rather technologyphobic. I remember have a slight interest in what a computer could do around the time that we bought our Macintosh 512, but then soon sworn it off as being too complex. In the past year, she bought herself a laptop computer. Too many companies and other organizations have been moving their sales, support, and other information onto the web and she eventually couldn’t do most of the things she wanted without the web and an email address.

My mom needed a new mobile phone. I don’t know what her thinking was, but she wound up with a XV6700. She then read the manual cover to cover and soon had the had everything set up and probably was using more features of a mobile phone than I’ve seen anyone else use. (calendar with appointments linked to address book, etc.) The qwerty keyboard was convenient for text messaging and email, and since she spends a lot of time in hospital waiting rooms and other places that she needs to have the phone off, the asynchronous messaging features.

It didn’t work out for long though. Eventually it started freezing relatively frequently. She learned how to reset it, but really thought there was no reason she should have to reboot her telephone. She brought it back to Verizon, and found out she was there on day 27 of her 30 money back guarantee period. When she brought it back, they told her they had lots of returns for similar complaints. She traded it in for a Blackberry.

Who would have thought it?

Last Sunday, I put up our sukkah so my family could celebrate Sukkot. Michelle keeps on suggesting that we could buy a pre-built portable model that could fold up and collapse and be hidden in the shed. I sort of enjoy the hacked together look of what I put together each year. A few of 2x4s, some 1x3s, A bit of wood lattice, some strapping, and you have something that looks like a rustic structure about 8x8x8 in size. I’d think that some thing that can be disassembled as easily as a pack-n-play seems be losing the essence of what a sukkah is supposed to be. (of course since I’m not Jewish, I’m not sure if my opinion counts.) Every year or two I split a board and need to replace it. This year one of the cinder blocks that I use to hold up the 2×4 I use for the sides.

This year, I had one of my younger brothers help out. (and of course in my family, “younger brother” means someone nearly 20 years younger. Closer to my children’s age than my age.) He’s been couped up in the house for a while and I figured he might actually enjoy some light carpentry work. A second person with a step ladder and another electric screwdriver really helps out. Other years, I’ve balanced a cross beam on top of the head of the 2×4 pointing up, screwed in one wood screw, moved the ladder to the other side, screwed in 2 screws, and then back to the original side for securing a little tighter. I spent more time moving ladders around and climbing on them than anything else.

After my brother and I were done, then the kids got to string up the fruit and vegetable decorations. (some real, some fake vegetables. There are enough fall or Thanksgiving decorations available for decoration that can serve as Sukkah decorations.

Soon I’m going to be faced with a large software system written in perl, and in needs of a large rewrite. The rewrite can either be a scrapping of the existing system or rewriting it piece by piece. Articles like Joel Spolsky’s Things you should never do, Part 1 imply that a rewrite is never a good idea. Martin Fowler’s Refactoring has some pieces on when to rewrite and when to refactor the code into a better architecture.

I figure the first step I need to do is to figure out how the existing application works. One obvious step would be to talk to the developers who are currently working on it. From what I’ve been told so far, most of the developers inherited the software from a different group, and large parts the code base are a lurking horror that no one dares touch.

I wonder if tools like Devel::Cover and Devel::GraphVizProf might help,  but I might have to adjust it to the Graphviz output a bit. (Initially I probably just want to see module by module connections, not the line by line detail that GraphVizProf shows.)

I wonder what other tools I could use to dig into and understand the source code of a large existing existing application.

I’ve been thinking a bit of how to gather quantifiable metrics the software development process. I know there is a certain amount of futility in my quest. Just yesterday, I was read a warning against “having your team manage the checklist, rather than using the checklist to manage the team“. But if I keep that in mind, I figure it might help if I have some simple objective measures that I can compare to my own observations. I want to make sure that the observations aren’t being skewed in my interpretation.

One place that I think I can look to for information is the source code revision control repository.  I’m figuring that information like:

• The number of commits over a range of time.
• The number of commits by user within a period of time.
• The lines of code with the most revisions (implies ignoring the open/closed principle)

and hopefully I could think up other measures as I go along.

I few weeks back, I noticed this slashdot article:  Algorithm Rates Trustworthiness of Wikipedia Pages and wondered if something similar could be used for source code.