Jawaad Mahmood in Tokyo

About two years ago, I was working full-time on an airline-related project.  I was the fresh-eyed mid-level programmer handed the project manager reigns, and pretty much told to build a white-label competitor to Kayak.  I learned a lot during that project, although unfortunately, the majority was “what not to do”.  Instead of a thorough design process, I let myself run with a database design I got from the CEO.   I didn’t ask any questions, and I often would spend about 13-14 hours a day in front of a computer screen, wondering why the project wasn’t moving forward (despite my best efforts).

In retrospect, the project was doomed because of a few reasons.

• Communication It was hard to communicate everything needed by text alone; with my own programming duties, I really depended on them to understand what I was saying.  I can’t blame anyone but myself for undertaking this task; frankly, it was unfair to expect them to accomplish their task without a detailed technical explanation of the task.  I didn’t press hard for the time to write it out properly, and it hit us hard.
• Turnover The outsourcing teams were quite underpaid and were almost understandably perfidious.  Most of them would leave as soon as possible; some actually listed the days until the end of their contract on their MSN profile.
• Fear I would constantly experience fear; I was worried about my job from day one, and afraid that my own stupidity kept me from keeping the project on-track.  This was not actually the case, but my lack of backbone at the time hindered the project.
• Lack of Process The process was best described at ad-hoc, and this was undoubtedly due to the Communication & Fear issue.

By 6 months into the project, we had a functional site, and I had finally grown a backbone.  Unfortunately, the economic downturn hit and the job had deteriorated into fixing bugs in WordPress, Dolphin and some video site (I forgot its name).  I feared completely losing all my skills, gave my notice and left.  However,  I’ve always wondered if I could build a better system given a second chance and no handicaps.

I decided that I could afford to spent one hour a day building a new airline search system from scratch.  Flighter (the aborted nickname a friend of mine had come up with) will be based on my rigorous “strictly object-oriented” style of programming, with testing and weekly goals.  I plan on checking in about it here every now and then.  Although I am starting it alone, I do intend on following a strict series of rules I made for myself a few years back (and which served me well  during my work on the Dogmoto social networking system)

1. The code will be readable.
2. Everything will be testable.
3. All code must be immediately usable; no building a model and leaving it untouched for 6 months, only to find out it doesn’t do what I want it to do!
4. Consistent naming through the usage of interfaces.

We’ll see how it goes!

About two weeks ago, a client contacted me about doing a quick one-day job for another company’s website.  Turns out the company (a local shipping company) had a bad experience with an old programmer and they had been referred to me by another client.  They told me that their main problem was that their entire website was slow as molasses, and more importantly, their contact form hadn’t sent any online moving requests in more than 3 weeks.  The main job was to get their contact form working, and then to see if there was anything reasonable I could do for the speed issues.  We agreed on my usual rate with a capped top and I got to work.

Turns out the old programmer had hired the cheapest outsourcing company he could find, and things deteriorated from there.  The content management system that was underlying the website was a poorly-coded system that was put together in a way that deliberately reduced code readability.  For example, certain functions had  nonsensical one-letter names, clearly meant to ensure that the code could not be read by anyone but the outsourcing company itself.   It was a classic “salt the earth” strategy.  Yet, despite their efforts, I quickly looked up the function names and created a quick list of what did what, ruining their ‘hard work’.  I can’t understand why they would engage in such immoral behavior, since it limited their own abilities; such coding made it harder to  debug code and bring new junior programmers up-to-speed with their project.

The site-specific code was not much better.  There was a lot of vestigial code that should have been deleted.  For example, one of the original requirements for the website was that it be usable  for both Japanese and English-speaker customers. Unfortunately, it turned out that the Japanese-language section would not work properly.  As a result, the Japanese-language functions had been completely disabled by the time I was approached by the client.  However, the original method used to fetch Japanese language menus was poorly done, and this had repercussions throughout the site.

After doing a one-hour code review, I realized to my horror that every bit of text on the website was loaded by a separate call to the database.  Undoubtedly, this was related to their attempt at making the site bilingual.  As a result, certain pages had more than 300 individual queries made across the network to the DB.  In my entire time programming, I’ve never seen a more inefficient system.  Fortunately, these calls were all being made through a single command.  I implemented a small cache for that command and improved the speed of the site 40-50 fold. This was literally a two hour job, and even a fresh-out-of-college programmer could have done it.

I knew that after my corrections the site would improve to the point where the client would forego any further use of my services, at least in the short term.  I needed money, and I knew I could have approached them with an offer to fix the speed for another thousand dollars.  However, I  prefer my reputation to money.  Only my reputation that will permit me to offer a fair rate for my programming work in an outsourced and increasingly competitive world.  Yes, I will lose contracts and work to 3rd world countries, but guess who they will call when they realize their website isn’t coming together?

Do unto others as you would have them do unto you applies to programming.  This means:

1. Leave code easier to read than when you saw it (Read the book by Robert C. Martin)
2. Do the best you can in the budget you have.
3. Don’t play on someone else’s ignorance.

I won’t pretend that these are the only rules that would apply, but if you can do these three, you are already in a better place.