My way or the highway!

So, I was doing a consultation this week regarding some database work and got to hear a little horror story from the owner of a site.

Please Note: The owner of the site has next to no programming experience. The only experience they have is dealing with the code that they were originally sold.

The owner of the site contacted me because they felt there had to be another way of handling this particular situation. What the problem boiled down to was the fact that they had 1 large table that had more than 256 columns in it! And better yet, the columns that were actually needed depended 100% on the “earlier” content of the table (i.e. the first few columns). To me, I immediately saw this table and was appalled. I thought to myself, well this obviously needs to be a mapping table, and treated as such.

After talking with the owner for a bit, apparently this was their first inkling too. However, the programmer “swore up and down that it could only be done this way”. Hearing that saddened me a little.

Now, you maybe wondering why this blog post is called “My Way or the Highway”. That’s because one thing that I have learned in my years of programming is the fact that there truly is no “one right answer”. In fact, every time I work on a programming problem, I myself come up with 3–5 alternatives before narrowing the problem down into which solution I’m going to take.

In order to develop applications, you need to take a few things into consideration and most importantly, leave the ego at the front door. In my opinion, this holds true for more than just programming exercises. Someone else to bounce ideas off of may help you see the problem in a way that you never even thought about before which could lead to a better overall application.

After peering through the code a bit more, it was clear to me that the reason why “it was the only way this could be done”, was because they wanted to be lazy when handling access in other pieces of code. All they really needed to do in order to make this mess manageable was to wrap the database call in some sort of data access layer. When they do that, they would be able to handle any updates/inserts that are needed and still send back all of the data that was required to process the data instead of that and then so much more.

In short, when programming, try your best to keep an open mind and focus on other alternatives and please don’t take the solution that “is done fastest” because that normally leads to pain points and wasted resources in the future.

Had this programmer done what the owner, who was speaking from what logically made sense to them, listened to them and re-evaluated their statement, then I wouldn’t have likely needed to be brought into this discussion at all.

I’ve been programming for years now and I still realize that I know just a tiny bit of the broad spectrum that coding provides. So, that is why I always ask others for their opinions and leave my ego at the door because at the end of the day, I want the best product out there. Not a decent product that is filled with patches that is being held together with bandaids and chewing gum. You only get that solid result from reaching into the depths of programming experiences both that you had, and that everyone else has had in order to get the best results!

Thanks for reading!