kentcowgill.org/blog

Here's a handy tip for writing code.

If you find yourself doing the following:

That's a pretty good hint that your object is written poorly.

Instead, your object should be hash based, and return a given hash value for a given hash key. Like so:

You'd think this is fairly common sense, but I just ran across some code that not only loops through a list every time it needs a particular $thing from an $obj, but it used the exact same code copied and pasted 10 some-odd times throughout a single file (and in many other places where the module is used too).

I invite you to peruse at your leisure a great book I've been reading - Refactoring: Improving the Design of Existing Code written by the same guy who wrote UML Distilled, Martin Fowler.

I'm struggling with some major frustrations at my job.

I recently learned of a workaround for a race condition that has been an annoyance for some of my coworkers for nearly a year. Pointing out the silliness to my manager was a bit fruitless - she quickly turned around and assigned the 'fix' to me.

So I took a look at the code.

It was a mess.

At least 27 different files call this code, so to properly refactor the code, all of those files would have to be changed and tested.

But there's no tests.

There can't be tests⁶. Why? Because these files are a mishmash of perl and HTML in a custom templating system which are sucked in and evaluated 6 ways to sunday on every web request. Files include other files, variables are set in weird objects, namespaces are a giant jumble, etc. so forth and so on.

And the people who originally wrote this code have left the company - my guess is in frustration. They were trying to rearchitect the code, but it was taking too long, and so were told to just hack it to make it work.

But surprise, there were performance problems, because the dynamic data originated from flat files on the filesystem which were parsed multiple times per page request. And this custom template system is running under mod_perl - why not make some persistent data?

So I'm writing an email to my boss, and struggling with whether to include the following:

“ I don't think further code reviews for $WEBSITE are worthwhile, since we lack manpower to make any changes. Further, since we don't have any tools to perform at least unit if not functional tests, it's impossible to refactor existing code without being certain nothing was broken in the followup.

Due to the lack of manpower and lack of morale in existing manpower, nearly every IT project will eventually fail abysmally and become completely unmaintainable and unscalable. $COMPANY will continue to struggle along and churn through developer after developer - assuming we are allowed to hire some more to replace the ones that have left in frustration. ”

But I don't think I can do it.

Would you?

⁶ Actually, I've been trying to find free time to finish the Test:: suite I've been developing, which is currently capable of splitting the perl from the HTML, evaling the code in its own namespace, running Perl::Critic and Devel::Cover on the code and HTML::Lint on the HTML, but I'm having trouble with the recursive templating creating new variables in the existing namespaces. Also since I lost half of my team members (including the team leader), it's a little tough to find that free time.

I don't mean to make this the "Andy Lester" week, but the company I work for is in technical debt -- there's no better way to put it.

For a little introduction on the concept of technical debt, there's a nice wiki page. But what brings it home for me are the slides from Andy's infamous technical debt, which are available on his website.

So what am I griping about?

Version control.

Love it.

Hate it.

Gotta have it.

Unfortunately, it's a big undertaking.

What we currently have in place is a script that does:

It even has enough brains to accept multiple files as arguments, even if they're in separate directories, and create the backup in a given files' subdirectory. While this (kind of) works, it's a pain for "rolling back", which I just had to do due to technical problems at our other office out of state. Especially painful when there had been changes to files that haven't made it to production, but the developer (me, in this case) is blissfully unaware of said changes, so it's not clear which version to restore.

Ugh!

Similar frustration for trying to re-restore the changes for eventual re-promotion.

But moving to a real^™ version control system is a chore. Why? Because there are 5-6 years worth of these archive files that would be nice to have as version history. Altogether, there are about 99,300 files total. And the perl program I wrote to import them into our version control system³ takes an average of about 3 seconds per file⁴. My math tells me that's about 3.5 days.

³ Perforce seems to be what the company has elected to use, even though the few times I've tried it, I've hated it. Nowhere as intuitive for me to use as more reasonable (and by the way, free) version control systems such as subversion.

⁴ Pitifully slow. But since the Perforce server is a bit far topologically, speed issues are to be somewhat expected.

I keep getting reminded of the story about the broken window I read recently in a great book I've purchased called The Pragmatic Programmer.

Most recently was this set of conversations between a coworker and myself, and my manager and myself.

Coworker Y: "Kent, can you please run sudo command xyz on the production cluster?"

me: "Sure, but only if you promise to fix the race condition that causes condition X on the production cluster."

Coworker Y: "I would, but it's not on my platter."

me: "Whose platter is it on?"

Coworker Y: "Coworker Z."

me: "This has been a known issue for nearly a half a year, hasn't it?"

Coworker Y: "Actually, about 9 months."

... time passes ...

phb: "Kent, does sudo really need to be run for command xyz? Can't you just¹ do it with normal user privileges?"

me: "I assume so - they wouldn't ask me to do it otherwise, no? BTW, the cumulative time taken to run or have someone else run [sudo] command xyz every time this happens is probably much greater than just fixing the race condition that causes condition X, which as I understand has been a known issue for at least 9 months."

phb: "They tried to fix the race condition and failed. But I didn't know coworker Z had been running sudo command xyz all along, I thought he had another way to deal with it. Until he comes back from vacation, can you take care of these requests?"

me: "I'd much rather the race condition get fixed."

phb: "I agree, however coworker Z is out of the office this week and coworker Y is swamped -- we will have to wait."

me: "Coworker Z hasn't been out of the office for 9 months, though."

phb: "Coworker Z and coworker W tried a couple of times and could not get it fixed."

me: "Did they exhaust the entire technical resources of our company?"

phb: "No one really had lots of time on their hands. If coworker Z tells me again they can not fix it, I will hand it over to someone else for sure."

I really wish conversations like this didn't happen.

I really wish that more people at my job cared more about what they did.

Why did coworker Z and coworker W give up?

Why didn't they ask anyone for advice?

Sure it doesn't take much time to run sudo command xyz, but how much time is lost from breaking your concentration, switching contexts into "firefighting" mode, running the command, and trying to pick back up wherever you left off? And then what if you're so distracted by this craziness that you have to write a blog post about? How much time gets lost then?

I really wish people would care more.

¹ Andy Lester pointed me² to a great rant of his about this very phrase "can't you just...".

² And a second article linked from Andy on complexity management (I think he's on to something here)

Ok, riding to my new job was a bit of an adventure, especially given that my ribs are a little sore from skydiving. But it was mostly good except for the rush-hour traffic in the loop - I think I'm going to avoid riding between busses as much as I can :) About 15.5 miles round trip, but I think I'll do more mileage when A) I have more time, and B) my ribs hurt less :)

And the baggy shorts were great, even though they acted like wind scoops to slow me down a lot!

So my Dad paid me a visit this past friday, and not only did I get him out on a bike, but he also gave me a huge sponsorship! Thanks Dad! I lent him my mountain bike (I think it's more comfortable than my road bike and I also think it takes some time to build up a rear-end tolerance for it) - and we rode to a bike shop for a helmet. I also picked up some baggy bike shorts and a mini-pump for emergency use (hopefully I'll never have to use it!). Our next stop - the Taste of Chicago! We stopped in for a quick bite of lunch and then we headed back home. Round trip, about 20 miles. It was a nice leisurely pace hovering around 10 mph, and we had some good time catching up while riding.

Did I mention I picked up some baggy bike shorts? Now I'm going to be able to ride my bike to work again! I had been hesitant to ride to my new job because it's much more corporate -I'd feel a little embarrassed walking into the office in my spandex. Baggy shorts are definitely the way to go! I also now (thanks to my Mom) have a great gore-tex biking jacket, so I won't even have an excuse if it's raining :) Stay tuned to see how soon I actually ride in! :)

The new job has a lot of my time and energy sucked away.. :(

As far as training, the last month has been terrible! I had a really bad cold and the weather was horrid, so up until about week ago, I haven't been on my bike all that much. Last week, I did force myself out on my bike. My original intention was to ride maybe 10, possibly 20 miles. After about 8, I felt so good that I decided to call up a friend (who lived pretty close to that 8 mile point). As luck would have it, he was just getting ready to go out on his bike. We met up a few minutes later, rode down the Lake Shore Bike Path to the Museum of Science and Industry (and actually just a bit beyond that). We took a break at a promontory looking out over the lake, shivered a bit (I was cold!), turned around and headed back. All tolled, about 35 miles. Nothing too special about that ride - I'm getting a little bored with the bike path :)

This past weekend, I finally got Lisa, my girlfriend, out on a ride with me! I lent her my mountain bike, bought her a helmet, and we rode down to Bluesfest on Saturday. We took it easy because it was her first time on a bike in years. That was about 13 miles worth of riding. Then the next day, I decided to do all my errands on my bike - I rode to Lisa's apartment to put up shelves, I then rode to one of my clients' office to do some work, and then I sprinted (as best I could wih the stoplights along the route) back home for a total of about 20 miles. I think this is significant, because I rode for at least 2 hours each day, and they were back to back. I'm definitely going to be working more back-to-back days into my schedule as the summer continues, because the vaccine ride has 5 days, back to back, with some fairly hefty mileage.