What did I get done this weekend?
Well, for starters I tried debugging someone else’s un-friggin-documented code for a shopping cart. This was a done as a last minute favor for a client of an old friend.
Seems that there were some internal management conflicts that left the company with encrypted (pre-compiled) PHP functions. That, coupled with crappy programmers who didn’t take backups often enough, and who developed directly on their main public website was enough of a headache for the best of programmers. I rate myself good with extended periods of pure genius coupled with bouts of sheer luck. Meaning? There still wasn’t a lot I could do*.
So as of right now their shopping cart is broken, their sales reports are all junk and a whole lot of their business is at a standstill.
Yes, the phrase un-friggin-believable is what came to my mind too.
1) No backups?
You know when the various books and magazines scream out at you “Take regular backups” ??? … listen to them dammit. Atleast a weekly backup plus whenever you are going to make major modifications to any files (even if you are changing some product images, back the old ones up, just in case)
2) Developing directly on the live system?
What the hell is wrong with some developers? use any regular PC as a backup/sandbox server. Put in some extra RAM and you’ve got enough processing power to play around. Get one already. Use it to test all development internally before you deploy on your company’s main .com domain for the public to see your error messages.
3) If it ain’t broken, Don’t fix it attitude.
If you don’t have the source code, it is broken. Fix it like your tail’s on fire.
Also, software is always broken somewhere. See how Microsoft issues patches? (ok, wrong example).
See how people bring out new versions like 3.1, 3.2, 3.25 of their software? Thats because there are (hopefully) fewer things broken with each higher version number. Websites might not have distinct version numbers … but thats no reason to slack off.
4) You would imagine that most medium-sized businesses, with an IT staff will know what to look for in potential hires.
Bloody wrong. Make sure you test the programmer for real-world issues, like using version-control, knowing how to document code (check his/her previous work). Make sure they know how to perform basic tests (unit testing? awesome). Go buy them a few good books … Ship It! is cool, as are many others from the PragmaticProgrammer series.
5) Do what you must … but for the nth time … Don’t put your company, your sanity and your future on the line because of stupid problems that can be forseen and solved!
* I even got down and dirty with the PHP session files, if you really want to know. Thats the last straw for many programming types.
20 Aug 2006 at 6:11 pm
Debugging someone else his code can be a living hell, as wel as disassembling things and such. Maybe it feels better to know you’re not alone in this, in fact, I think http://thedailywtf.com/ might be an entertaining read after a late night (or in your case weekend) debugging session.