SlowerBuffer

Programming and Technology Related Stuff

Just Works

Read this post from Dr. Drang concerning bugginess of Mail in OS X Mavericks (and mentions in passing issues with iCal, Address Book, and Messages).

That, in fact, is the most annoying thing about this mess. Apple has broken the covenant. The deal was that I get a mail client that isn’t fancy but works, and in return I don’t complain about a lack of features I’ll never use. It’s a simple arrangement that’s worked for nine years, and now it’s all this.

It just works.

Rebranding Is Hard

A few years ago my company went through a rebranding excercise and got themselves a shiny new logo.

All of the new applications that my team was working on were fully reworked with this logo and all of the associated branding in mind. However no time was allocated to rebrand my project, our oldest (and most used application), partly due to other development demands, and partly due to the fact that as our oldest application it barely met the previous branding standards (as it predated them as well), and really didn’t mesh visually with anything else in the company anyway.

We were asked to simply drop the new logo in and be done with it. The colours of the new logo had been slightly tweaked, but were mostly the same, so while marketing wasn’t happy about it, it didn’t look too different than before.

Rebranding is always much more work than people at first think.

I mentioned that it would probably be more effort than simply swapping the logo in one file, but was mostly ignored. We used page templates, so they thought it would be a one line change in a couple of template files at most.

Of course, our application was 10 years old, had had a dozen or two different people touch it over the years, had vastly increased from its original scope, and had had some partial rewrites and refactorings that touched some areas, but not others.

With this sort of history, it’s only a very very well-controlled project that won’t have redundancy, inconistancy, and odd bypasses and cludges. There are going to be pages that were added later in an application’s life that didn’t or couldn’t use the original templates for whatever reason and have the logo on them somewhere. Or even better you may find a page rendered entirely from a servlet making no use of templates whatsoever with its own logo instance. An application may have bloated to include several logo files hidden around in different folders, with odd rarely visited pages linking to one here or there. There may also be other things that you wouldn’t even think of, like an external link to another barely maintained site filled with old static content. To make things worse, everyone’s used to seeing the old logo and so remaining instances of it don’t neccessarily jump out at you on random pages where it should no longer be.

These are all good examples of why it’s good to keep your code clean. But, as I said, most applications that have been through a lot of years and a lot of change will be like this.

It wasn’t much actual work for us catching all of these logo instances, but it certainly wasn’t something that happened overnight.

For a couple of months during the developement, it seemed that every time we passed something to QA, or gave a demo to the bussiness folk, someone would notice an old logo sitting somewhere on the page. In fact, some of the instances weren’t caught until after the release rolled out.

For instance there was a help documents page where a modified logo had been used as a list bullet point. It wasn’t the general logo file, and it was small and innocent on the page, so it wasn’t noticed. And then there were the help documents themselves, which were pdfs and loaded with uses of the logo. No one had thought about those (and they weren’t in the actual code so searches missed them). The same thing happened with some crystal report template files.

Eventually the process was done, but it was not the 5 minute job that had been given to us, and think how much more it would have been had we ACTUALLY rebranded things rather than dropping a new logo over an old.

So, why do I bring this up? Hockey season has started, an I am in a fantasy hockey league. Yahoo has done a makeover in the off-season and things look a little newer. They’ve updated the fantasy site and also the logo to their new one.

Rebranded Yahoo Fantasy Hockey logo

However, the other night I opened up the live StatTracker and…

Old Yahoo Fantasy Hockey logo where it shouldn

Bam! Old logo.

Rebranding is always much more work than people at first think.

The Right Trade-off

Gina Trapani had this to say today on twitter:

I cannot agree more. That is all.

Questionable Code: It Seemed Like a Good Idea at the Time

I write this as a bit of a goodbye to my current job, which I have enjoyed greatly over the years. Thanks everyone!

My first wish is that when my soon-to-be former co-workers come across any questionable code I wrote a few years ago when I was inexperienced that they don’t judge me too greatly.

My second wish is that when they come across any questionable code I wrote last month that they don’t judge me too greatly.

I am switching jobs, and as part of that have been working to transferring some the areas of code where I have been the primary (or only) person developing or maintaining.

So, I’ve spent the week sitting down with one of my (soon to be former) co-workers going over a large component that I helped write, answering: “What does it do?” and “How does it do it?”. Of course while discussing the latter, inevitably another questions comes up: “Why did you do it this way?”

This can sometimes be a hard question to answer. Especially if it’s been a few years since you last worked on it. It can also be an awkward or even embarrassing one.

In this case my co-worker pointed out (quite correctly in my opinion) that the code seemed vastly more complicated than it needed to be. As soon as she pointed it out, I could see it too: the section was a massive and over-engineered piece of code. And at first, I couldn’t really answer her (or even remember myself) why.

Thoughts went through my head like: “This is way to complicated.” and “What was I thinking?” and “God, I hope she doesn’t think that I’m a terrible coder.”

And then, slowly, I begin to recall some of the reasons. I’m sure this is a list that we all recognise:

  • “We were eventually planning to do thing B with this too, and so had to account for it, but thing B never came.”
  • And “I never really liked doing it this way but the guy I was working with pushed for it.”
  • As well as the opposite “I kind of pushed for my design but in hindsight the other guy’s would have been slightly better.”
  • To the all-to-common “Well we were rushed and didn’t have time to do it the way we wanted.”

I’m sure each of these has happened to us from time to time. Hindsight is 20/20 and project needs change over time. A few years down the road, something that seemed like a very reasonable idea at the time, can turn out to be an over-engineered mess or even too simplistic and not robust enough. Projects can be rushed with intentions to revise later that never happen.

These are problems we all face and must always work at, and we have to keep our eyes open for them. There are certainly many sections of code in projects I’ve been a part of that I know need work, but as this experience pointed to me, there are also sections where familiarity makes it easy overlook or to just think “That’s just how we do it”.

In the end I was happy for the chance at a code review, as it made me re-examine some code that I had become accustomed to, made me reconsider better ways to do it, and left the company with not only a good understanding of how it’s working now, but also with some solid suggestions for improvement.

You Want a Hash in That Vector?

I came across a few methods down in our database code yesterday:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
    /**
     * Transforms into a hash of Hashtables
     * @return String   - is a string representation of this object
     */
    public HashMap toHashofHashes() {
    .....

    /**
     * Transforms into a Hash (groupBy) of vectors of Hashtables (rows)
     * The groupBy parameter is the column value to group by.  This group by value will
     * be the key of the top level hash rows are represented as hashes in a vector
     * (representing zero to many rows for a group by value)
     * @return String   - is a string representation of this object
     */
    public HashMap toHashOfVectorsOfHashes(String groupBy) {
    .....
  
    /**
     * Transforms into a vector of Hashtables
     * @return String   - is a string representation of this object
     */
    public Vector toVectorofHashes() {
    .....

The classes haven’t been touched since 2006 (and even then the change was to logging), and were filled with raw type warnings due to the unparameterized vectors and hashmaps (and a whole slew of other warnings that never got cleaned up in the conversions from Java 4 to 5 to 6 to 7).

I took a crack at cleaning it up and got:

1
2
3
4
5
6
7
8
    public HashMap<String,HashMap<String,String>> toHashofHashes() {
    .....

    public HashMap<String,Vector<HashMap<String,String>>> toHashOfVectorsOfHashes(String groupBy) {
    .....
  
    public Vector<HashMap<String,String>> toVectorofHashes() {
    .....

Not exacltly pretty.

Next step will be to figure out when and why these things are even used and hopefully update the documentation, which is clearly lacking, as well as wrong (return type is clearly not ‘String’). Better yet, maybe I can just remove these hideous things altogether!