two databases, one column

I feel fortunate that I don't experience a "WTF?!" moment on a daily basis. Although sometimes, it does feel like I'm in Groundhog Day, perpetually experiencing the same WTF?!s over and over again. Today was such a day.

The application that I'm working on talks to two databases. In one database, there's a table called user with columns like id, firstname, lastname, ssn, and so on. The information in some of the rows in this table has also been stored in the second database. This is done for reasons of efficiency, so that when querying the second database, we don't always have to dip into the first database to get user information.

This seems perfectly reasonable to me, except for the way that it was done. Way back in the stone ages of our application, someone decided to store all the user information in a single column in the second database. It is stored as a set of key-value pairs in a CSV string, in a column called user, like this: "user=3378,first=John,last=Smith,ssn=123456789,..."

Since I first encountered this, I've been cursing scratching my head about why someone would decide to store all of this information in a single column. It makes queries more difficult to read and write, because it requires regular expressions to extract single items like the social security number from the user column. I can imagine this is also a performance hit.

In addition, whoever decided on this format did not replicate the user table column names for the keys in the CSV string. So the user.firstname column in database 1 maps to first in the CSV, user.lastname maps to last, and so on. This makes life more difficult when searching the code base for all queries related to a particular piece of user information. I recently fixed a bug caused by this mapping difference.

I'd love to have a conversation with the person who decided to do things this way. It would either be enlightening, or just plain crazy.

networking

I just laid down some serious cash out of my own pocket to go to a professional conference. I should do this more often, I guess. It's difficult to justify it based on results. Does the conference pay for itself, in the long run? I have my doubts. But I expect it will considerably improve my mood, at least for a little while, and I can really use that.

Before going, I should to do some reading about how to network effectively. Without feeling (or acting) like a leech.

please talk louder, I can't hear you

(200/365) Shhhhh CC BY 2.0
by dm-set

The personnel manager of my company is seated in an office near my cubicle. This morning, when I arrived, she was engaged in what turned out to be a lengthy conversation with her assistant. The conversation was loud, and large pieces of it drifted into my consciousness. Quite a lot of it was of a personal nature. At times the conversation would become muted, at which point I surmised they were talking about something (possibly work related) that they didn't want others to hear about. This was an indication to me that they were aware of the fact that people sitting nearby could hear every word of what they were saying.

Later, around 10 am, the guy in the cubicle adjacent to me began having a loud and detailed telephone conversation about his car loan. This went on for about five or ten minutes.

Then at around 2 pm, a guy further away began having a rancorous phone conversation, apparently with a car mechanic, about the unsatisfactory service he'd received. Despite the fact that he is two rows away from me, I could hear every word.

In between all this was the incessant chatter from two nearby cubicle dwellers who can't seem to stop free associating about non-work related topics for a large part of the day.

I think my number one complaint about my current job is the incessant noise due to inconsiderate coworkers who have different standards about what constitutes appropriate workplace discussion and the volume thereof.

I am a programmer, working at a software company. That means I spend long hours thinking in front of a computer. Ideally, I'd be sitting in an almost noise-free environment, with infrequent interruptions. For example, right now I am at home typing at my computer. There's a bit of noise from the apartment across the hall - I sometimes hear a child making, well, child noises. Sometimes there's car noise from the parking lot. Overall, it's pretty quiet, and there's no sound of people talking. At home, this is true all day long.

Normally, I am a very focused person, and I find I can frequently block out the conversation noise at work. After about a year at my current place, that no longer seems to work. I've noticed that several coworkers use headphones. I don't like headphones; they eventually begin to hurt my ears. Further, I do not focus well with background music drilling into my brain non-stop. I work much better with quiet, and it's frustrating being forced to take steps to block out noise which should not be there in the first place. Because these people are not even having work-related discussions. They are just blabbing about personal stuff during work hours.

The company culture overall encourages this. I'm within earshot of a couple of more senior people who have loud phone conversations (work related or personal) from within their offices. These are not cubicle dwellers, but they still find it necessary to leave their doors wide open when talking on the phone. What's amazing to me is that these people do actually sometimes close their doors when on the phone. Presumably this means something particularly private is being discussed. Don't they realize that no one wants to hear their non-private discussions, either? Just be considerate and shut the door when having a conversation, for crying out loud!

In my list of grievances at my current job, this ranks pretty high. The noise is bothersome, but just as aggravating is the apparent lack of consideration by numerous employees. Sometimes it seems like these people are deliberately talking loudly as a way of showing how important they are. Or maybe they're just thoughtless blowhards. Either way, I wish they'd STFU. But I guess that's not going to happen, so I need to put my ass in gear and start looking for a new job.

how much time will it take?

Clock Top / CC BY 2.0
by Chris Metcalf

I'm one of just a few developers working on a poorly supported software product. The product was barely maintained for the last several years, since it was first released. Many moons ago, it was decided to give the product a complete overhaul, front end and back. Meantime, the main caretaker of the product wisely decided to leave for greener pastures. He was tasked to add as many new features as he possibly could before leaving, and he did so.

He pretty much had free rein over the product while adding enhancements and rewriting code. So far as I can tell, there was no extra pair of eyes checking to see what he did. Management trusted this developer to do everything in the "correct" way. The problem with that lack of oversight is that you are trusting a developer to do everything the way you expect without much (or any) feedback. In many cases, even the product owner doesn't know what to expect, so this imputes impossible, magical abilities on a developer. Naturally, some things are not working correctly, and additions have to be made.

Next thing you know, I've been assigned to finish up the work that was started by the departing developer. There are areas of the application that are incomplete. The code base is quite large, and the application is complicated. I don't know what things work or don't work until I happen to run across them while debugging some other problem.

I've been asked to supply an estimate for how much more time will be required to take this project to completion. So far, I have equivocated, saying that it is very difficult to make that estimate at this point. I am still unfamiliar with a lot of the code base. No one knows how many bugs are in the current iteration of the product. I don't have a specification for what needs to be done, or a checklist of things that have been changed or are still needed.

Truth is, it looks to me like there is still a lot of work ahead, but I can't tell how quickly that can be done. It's even harder to make an estimate because one developer keeps getting pulled away to put out fires in another development effort, so progress is even more unreliable than it usually is in software development.

How do you make an estimate in a case like this? I have a gut feeling for how much more time is needed, but I can't justify it. I'd like to take a few days to run through every feature in the product and see just what is and isn't working. At least then I'd have an idea of how much stuff is still broken. But management would not approve that. I'm supposed to spend every minute developing or bug fixing.

So I can't come up with any justifiable estimate. Meantime, management decides to supply their own deadline. I believe this date was pulled out of thin air; it certainly is not realistic. I don't understand why you'd pull a deadline out of a hat and not expect to be disappointed. I've seen this happen with another project. They kept rescheduling the deadline for months. It makes no sense.

fragile (code) - handle with care

shards CC BY 2.0
by zappowbang

I'm working on a "legacy" software system. Legacy means different things; in this case I mean it has been around for a few years. The original developers are long gone, and there are numerous sections which are a mystery. Even more annoying, the code produces mystery entries in the database. There are columns with fields that have dual, hidden meanings. There are extra rows for undocumented special cases.

One of my colleagues, let's call him "Mr Eager-Beaver," recently decided he'd had enough, and removed some lines of code which had been adding apparently extraneous information into the database. He's not an idiot, so he tried doing this on a test system first, and found that nothing went wrong. So he argued for committing the change, and so it was.

Unfortunately, the application is extremely large and complex. Being finite, I'm sure you could design a suite of tests which check every possible feature in the application. However, the company motto is "we will test no code before its time." The end result is that we actually have a very limited suite of tests for this application. Further, from a QA perspective, you can't just go in and hit a few pages, click a few buttons, and declare a code change has done no damage.

So ever since this change was committed, we've been uncovering bugs related to it. In a few dusty corners of source code, the application expects to find the missing information in the database, but doesn't, and barfs.

It wouldn't be so bad if these bugs were easy to find, or if they could all be dumped on the original hero who did the refactoring. No; what happens is that you have no idea what is causing the bug until, after several hours of research, the realization dawns on you: "Oh, this is due to Eager-Beaver's code change!" At that point, you can fix the thing pretty easily, and there's no point in reassigning the bug to him.

So far I have had two such bugs assigned to me. Eager is actually a pretty decent guy, so while I do get an urge to come over and give him a good metaphysical ass-kicking when I finally discover the source of the bug, I don't. I can only hope he's been assigned his own fair share of these bugs. And that he'll be as nice to me, whenever he uncovers some code crime of my own.

stack overflow

I've never had much need to write recursive functions in my programming career; I've written one perhaps two or three times, all told. Hence, I haven't paid them much attention, and still don't really know much about them.

It turns out that interviewers are quite keen on asking questions about recursion; perhaps this is because there's a heavier focus on them in CS classes than there is a use for them in reality?

The first time I encountered a question about recursive functions during an interview, it kind of threw me. Why ask a question about something so rarely used? My response was that, yes, I've written them, but rarely, and I try to avoid it when possible because I find them confusing - I have a fear of writing something that will result in an infinite recursion in some subtle case. It was during this interview that I learned that recursive functions can lead to stack overflows. Thereby proving that interviews can be useful, at least as learning experiences.

Well, today I caused my very own stack overflow by creating a recursive function, albeit unknowingly! I had created a Java class which extended another class, which mostly had getters and setters. The intention was to eventually implement these methods in the child class, but meantime I had the child class override the parent's methods, and just had them return the results of the super class methods. For example, I had the getFoo() method call the superclass method, super.getFoo(), and so on. Only, in one case, I inadvertantly left out super and had the getBar method return getBar - so the method called itself recursively. When I ran the code, I immediately saw this huge stack trace in the output. At the top it said "Exception in thread ... java.lang.StackOverflowError. This was followed by 1024 repeated lines giving the method which had generated the error.

I don't recall ever experiencing this in my entire career, and I could immediately see what had gone wrong, so I found it very entertaining (perhaps I am too easily amused).

the blame game

http://www.flickr.com/photos/shockie/ / CC BY-SA 2.0

There are a couple of developers where I work who are in the habit of making public announcements when other people's bugs are found. They'll write it in a bug report: "I found these lines of code written by X", followed by the egregious offending lines of code. Or they'll announce it in a meeting: "Yesterday, I was working on a bug that had been assigned to me, but it turned out to be a problem introduced by Y's implementation of the foo feature."

Is this normal, common, or in any way productive? In my view, it is counter-productive: there's an element of public humiliation in it, where there doesn't need to be. And it does no good that I can see; rather it engenders a hostile and competitive work environment, whereas I prefer a cooperative one.

I am probably too thin-skinned about this, but it really grates on me. My gut reaction is to want to retaliate by publicly pointing out every bug made by these finger-pointers.

However, I see no reason to publicly call someone out on such a thing. Instead, I apply my default behavior to everyone equally. If I find something wrong in someone else's code, I fix it, and in the bug report, I'll write something like "the problem was in the implementation of foo in class Blah, where == was used instead of the equals method." If the person is still at the company, usually I'll walk on over to them, point out the problem, and ask if they agree with my solution, or if they want to fix it themselves. I don't do this to rub their noses in it, but because that's the way I'd like to be treated - I want to know when I've made a mistake, and be given a chance to correct it.

To be fair, the finger-pointers do, on rare occasions, point out bugs of their own making. So maybe they're just applying their own standards to everyone. Still, it seems like the standard (and friendly) behavior is to point out a bug, but not call attention to the bug creator. I wonder what motivates those who insist on playing the blame game.