Wisconsin Represent

Some minor reorganization of my blogrolls (see the right pane there) and now I have a special section for the Wisconsin guys.

Notice there are precious few over there. If you're a technical blogger here in WI let me know: I'd love to add you (or at least give you a chance).

Computer Programming... the board game?

That's right kids. Just in time for Christmas!

Over at The Halblog, my sister-in-law is blogging about C-Jump, the hit board game of the season.



(article from a while back on Wired News)

Adventures in Refactoring

My current 1 year - 6 developer project is winding down and I've found myself the last man standing. As others have made the conversion to other projects, I've been left awaiting the final go ahead for deployment. In the meantime, I've got some time to take a look back at this mountain of code and do a bit of cleanup and refactoring.

As with most projects we had a variety of talent levels but felt like we did a pretty good job of monitoring the code base and refactoring as we went... I don't know if I would say that this feeling was wrong, but man there is a ton of code to be cleaned up in here.

Two days later I've refactored countless classes. Straight-up deleted probably 2500-3000 lines of completely unused code. And corrected 2 dangerous instances of blatant disregard for thread safety.

Many of the things I'm encountering are straight from Kevin Cauble's 1991 Syndromes of Forgotten Programmers (recently resurected over at developer.*).

All that deleted code
90% of the time this has been code that was never used. Thousands of lines of code resulting from copy/paste without any (necessary) tailoring and trimming. The cost of executing of the unnecessary code is quite low, but the cost of confusion is enormous.

All that refactored code
Most of this was objects stepping on each other's toes. Logic that should be intimate to an object but instead it's in 5 places - and, of course, never quite exactly as efficient and accurate as it should be.

The threading issues
Is there a line in the intro to Java book that says: "When you're first getting started, make sure to always implement the Singleton pattern."? The thing about only having one instance of an object is that... you only have... one... instance... of the object.