It’s the business model, stupid. How terrible programming can lead to big money.

The last few projects I’ve been working on have involved paging through lines of poorly programmed and utterly atrocious looking procedural code in PHP. I’ve mostly been mopping up for other consultants, some outsourced, some not. I’ve questioned on several occasions whether or not a 5 year old was responsible for the terrible programming decisions made.

And I’m not talking about the differences between using a switch/case statement instead of an if/else structure. I’m talking about creating 10,000 global variables and carrying them from page to page instead of populating arrays and objects as needed. Database normalizing? What’s that? We’ll just keep repeating the customer name and address for every line item of every order. This stuff should be Programming 101. Apparently these programmers were absent that semester.

Now, are you ready for the kicker? These terrible apps are all making boatloads of money for their respective companies. I’m talking millions… sometimes tens of millions of dollars a year… being sucked into the company coffers by a web application held together with the programming equivalents of toothpicks and dental floss. Shocked? I was. It’s taken me awhile to shake off the disbelief and get down to the factors at play.

The key here is that each of these projects has a really great business model. Each business model is sound and complete, providing for multiple revenue streams through a single core product. All the projects were pretty cool ideas too, coming from the “Why didn’t I think of that?” department. They aren’t web-based services for programmers, tech folks or companies. They are services for real everyday people. People that think aol IS the internet.

The common elements with these projects:

• Great business idea.
• Terrible system implementation.
• Big money coming in, from common web surfers, regardless of the terrible system.

Sound like anything else you may have heard of? For me, it’s really revolutionized my thinking on a lot of items. People will come and pay for services they want, regardless of how difficult it may be to purchase them. And they will put up with a crappy business experience if the service provided is valuable enough to them. So you can code all you want, make all those objects perfectly encapsulated, make the database fly with tight queries, stamp out every bug you find -- that isn’t going to make you any money. Because it’s the business model, stupid.

Yahoo customer service is amazing

I use my.yahoo.com/ all the time lately. Obviously, I use the email and the weather feature is nice. I have both of these on my front page. But some of the other tools of my.yahoo.com have become indispensable to me, particularly, the bookmarks, notes and briefcase. I use these to store files and information of a temporary nature that I can use from both home and the office.

Yesterday morning, my yahoo briefcase broke. I’m not sure what happened but when I was moving a fairly large database file from one folder to another in the briefcase, it came back with an error. Then, no matter what I clicked on in the briefcase, it wouldn’t go anywhere or do anything. Gasping at straws I filled out the help form at my.yahoo. Lo and behold, yahoo customer service actually wrote me back within 12 hours AND fixed the problem.

I couldn’t believe it. I was dumbfounded -- a free web-based service that actually takes the time to support their users. I’m not even a “customer” so I don’t even know if that’s the correct name to use, but yahoo customer service is amazing. Enough said.

Creating software products versus Supporting software products

For the first time in a long time, I find myself working on applications in a revenue generating department of a company. It’s pretty refreshing. I’m working in online product delivery so the web applications I work on are actually sold to customers via subscriptions – they gain access to a particular application on the web for the length of time that they have paid for. The business focus is to create products and the financial focus is obviously to make money by creating products that customers want to buy. This obviously has a good side and a bad side.

The good side is that it looks like I’ll be working on “new” things a lot. Most programmers love “new” stuff and I’m no different. The bad side is that “old” things aren’t given quite so much concern. Refactoring existing code to run more efficiently is not a priority. It’s almost looked down upon. If a bug arises in an existing application, the focus seems to be to fix the bug in the smallest way possible and move on with the “new” stuff. Still, there’s quite a bit of adulation to go around when something “new” is launched. That’s because it can make money.

Most of my career has been spent working in various IT departments. The business focus in the IT department is one of support. You have to support the other users and the applications they use.

The financial focus of most IT departments is one of saving money or holding onto revenue. You improve programming processes so that applications are quicker and more powerful. This enables people to do more work in less time. But in IT, no matter what you build, you are still only “supporting” the business. You aren’t creating business. No matter how good you are, you aren’t making the company money. You are costing them. You may be helping them to save more money than previously but make no mistake -- You are costing the company money. And you’ll be first on the chopping block when job cuts need to be made.

Personal Disaster Recovery for the Masses

A few people make fun of me because I have a personal disaster recovery plan for my computers, data, and applications that are located in my home. These people aren’t in the IT industry. Those in IT usually nod thoughtfully and muse, “I should do that too.”


At least once a month, I back up all my important data and documentation, burn it to some CDs and place it in one of those lockable fire-proof boxes. I include my bookmarks and any software that I’ve downloaded and installed recently, like some of the open source projects I’m trying out. If I’m working on a specific project from home, I copy the data to multiple machines daily and usually burn it to CD every couple of days.


I also put my address book in the fire-proof box in various file formats as well as actual print-outs. This includes all my business contacts, credit card and utility companies, insurance companies, etc. If a fire ever burns my place down, I just need to find that box in the rubble, open it up and start making calls. I think most people could benefit from this regardless of whether or not they’re in IT.


My software documentation usually includes step-by-step instructions for getting back up to speed should disaster strike. I try to document everything as I use it the first time so that documentation isn’t a separate chore. I still have a lot of work to do here but I am definitely making progress.


Well, this weekend, my Fedora linux box up and died. The power supply keeled over (at the ripe old age of 10 years). When the power failed it corrupted the hard drives because it wouldn’t let me boot back into linux. So, I had to replace the power supply and then just re-install linux. I had documentation on all the options to choose during install. I also had docs on installing/configuring Apache, mySQL, PHP, Perl and its modules.


Now, I am far from perfect and there were a few instances where I had to make educated guesses on setups but I was sure to add those into the docs as I went. There’s a kind of recursive nature to disaster recovery. The more disasters you have, the better you get at it I suppose.


The whole install and configuring process took me only about 5 hours. This could have been faster but my linux box is a Frankenstein, with most parts being pretty old and slow. I was pretty impressed that the whole process only killed one morning.