Passwords, Security, Tech Snafu’s & Support

Well, with a title of a blog post like “Passwords, Security, Tech Snafu’s & Support” I am going to cover in this blog article a bunch of thoughts on the support process that I have navigated in the past couple years with our speed dating company.  This means I may chat about the importance of stability, password security, or issues I have run into trying to keep things running, since there are down times and bugs.

First Things First:  What The Heck Have I Gotten Myself Into

Nothing I am saying here is a hard and fast rule.  It is based on my experience.  Let me first start with the overall situation I am in.   Back in 2001 I helped a certain person create a speed dating business.  By help, I mean I wrote all the web application code to create a website so people in many, many cities could both run speed dating events and sign up for events.  This company, called Pre-Dating, went on to be sold to Cupid.com.  When Cupid no longer wanted it, they sold it back to us, and in 2010 I redeveloped the code again from scratch and we recreated the business on a back-end platform called Take It National, i.e. Takeitnational.com.  While I did all these things and built all these systems that work (nicely), I still profess that I am by no means an expert or a serious, serious programmer.

1. It Works

The most important rule to me and a lot of top developers I know is that it works and does not crash!  This means that my code is not sophisticated, not always in the code hall of fame or MVC perfect or something to write an article or home about.

2. No Bugs, But There Is Downtime.

I hate bugs, and of course I work toward no bugs.  Who doesn’t?  There are some down times, but I will get into when that happens and why it will eventually happen. There are a dozen lessons I learned over the last 12 years dealing with these systems, but the fact is you can not make a perfect system, because even if you made the system perfect, there still would be a crash one day, especially if that is the day the operating system, hardware or the software language gets upgrades.

3. Upgrades, The Bane Of My Existence.

90% of my bugs today are upgrade related.  For instance the big one recently was an upgrade to PHP Version 5.4 from 5.2.  I found out about it when I got a call from the site manager who told me the site was offline with 404 error.   After a little bit of research reading through the logs, I realized that the errors we were getting were due to an upgrade in PHP.  I don’t even know when there are upgrades of languages.  And why would I think an upgrade would crash my system?  So, I found out eventually that this little note on the official PHP site said, hey you had 12 years of us saying this function is going away and to change your code around…

4.  Build For The Next Guy.

One thing I have taken into consideration is building a system where another programmer who knows PHP enough can easily take over and work on it.  I have even gone as far as keeping code in very specific directories so another programmer could take over and figure it all out.

5. Build Like It Will Be Around A While.

So how would I know that 12 years later, a couple versions of my code would still be running.  I didn’t.  Some guy may have written some mainframe code 30 years ago that is still in production.  How would he know that would happen?  We don’t.  But taking a few things into consideration, like not using the most sophisticated ways of doing things helps as well as making sure the code can easily be moved between servers.  For instance, we had an application a few years ago that was looking for an E: drive for an extension, this was ASP, and we had just moved the code.  There was no E: drive!

6. User Errors

Then there is the case where there looked to be a major error in the system, but the error was caused by user data entry.  The users had specifically added or changed something that caused the bug.  This can happen when you leave back-door admin openings (like text fields with no rules) for administrators to add stuff they are not supposed to.  This is why I am becoming more and more negative about HTML content apps on the back-end versus text.  With HTML you can mess up the application easily.  Most important thing here is to check to see if the problem is user entry created first, before jumping in and programming.

7.  The Once In A Lifetime Bug

There is this one bug that happened to me over the years that drove me crazy.  A user with an Irish last name, like O’Neil, wanted to make sure their name had an apostrophe in the name.  So they tried to force their name through the email signup with an apostrophe.  Later on that messes up the application in that it can send a stop code or start code message to the system.  So I fixed this and these users could not enter the apostrophe anymore.  Meanwhile a few years later one of my admins gets a call from a customer and then forces the apostrophe into the system via an admin screen.

8. Using System Email Addresses

There is an article that basically says that they got hacked using their company email address vs. using a Google email or large system email address.  The reason this can happen is if the hacker gets control of the mail system.  How does that happen?  They hack into your GoDaddy account and redirect the mail services to their own server.  This has happened a few times recently.   And with that, they are able to reset your passwords on sites like Twitter, Facebook even Paypal.  So, what I am saying is it is best to use a Gmail or Hotmail email address for the admin accounts, because they will never get control of the back-end of Google.  Obviously bad things can happen as well on Google, but less likely to lose control of the overall domain.

9.  Solve Things Early

General Schwarzkopf had a great saying, (I am misquoting him here, i.e., sic) that “The Quicker You Make A Decision, The Faster You Have Time To Change It”.  In other words trying to get to the problem asap.  So that is why I am always available for a support email, AIM, SMS and make sure the issues are resolved as soon as possible.  It may take time to fix things and figure out a problem, but it is important to solve those problems as quickly as we can.

10.  You Can’t Think Of Everything

I am guilty of many things, and as technology gets more sophisticated I become guiltier and guiltier as I know less and less.  You can’t master everything or know everything.   What you can do is learn what does not change so often… things like MS Excel and Linux.    In 1989 I went to the book store and there were only 4 or 5 books on computers in local bookstores.  Those days ended with thousands of books. And finally today, most of us don’t read books, but we can find 10,000+ articles online that help us solve things.

Leave a Reply