There’s a dangerous tendancy in the programming industry to spend one’s whole time fire fighting.
Because we’re largely deadline driven, there is always pressure to get things done yesterday, which inevitably leads to corners being cut in order to ship stuff on time.
Some of this is pragmatism, and entirely justified in the context of needing to turn a profit in order that everyone gets paid - but I believe that a big danger lies in the fact that fire fighting is habit forming. It’s a mentality which is very easy to slide into, and once you’re in it, it is hard to escape.
If I had to sum up a programmer’s fire fighting state of mind in words, it would be “I haven’t got time to do this properly”. Most of the time this is utter bollocks. A more accurate translation would be “I can’t be arsed to do this properly”.
Unfortunately most technology projects are run by non technical people who aren’t in any way qualified to tell which of these two statements applies in any given situation. Worse than that, they actively encourage the “haven’t got the time” mentality, which plays right into the hands of the “can’t be arsed” mentality - “look boss, it should have taken two weeks, but I got it done in a day (it doesn’t work for a few edge cases which I haven’t spotted yet, it breaks encapsulation, doesn’t follow any of our standards, and is totally unmaintainable, but did I mention that I got it done in a day!).
Larry Wall is fond of saying that a truly great computer programmer is lazy, impatient and full of hubris. When he says "lazy", he means in it a good way - as in "I don't want to do the same damn thing again and again, so I'll do it properly now, in order to avoid future wasted effort".
Unfortunately, the vast majority of programmers aren’t great - they’re just lazy - and the kind of laziness involved in the quick bodge is seductive. They live in a world where most people (especially their bosses) don’t know what they do or how they do it. What begins as a “I know I shouldn’t, but I’ll bend the rules just this once” soon becomes second nature, to the extent that the part where the programmer works out whether they “have time” to do it properly gets missed out entirely, and it’s just assumed that there isn’t time. Worse still, many programmers don’t even for sure what “properly” actually means. They may know it in an abstract, “this is what the lectures said” way, but they haven’t learnt the truth of it through bitter experience. The quick bodge method seems to work fine (for a while), and by the time they realise that it doesn’t actually work at all, it may be too late for them to get out of their bad habits.
This isn’t some sort of calculated wickedness on the part of programmers. There’s nothing suprising in it - it is simply human nature - which is the very reason why it should be actively fought against by managers who have the foresight to encourage quality and excellence (not to be confused with self-indulgent noodling).
Most corporate environments strive hard to keep their employees cocooned away from any “negative” temptations, such as the temptation to read email, surf the internet, or (heaven forbid) think about something apparently unrelated to work. This is usually futile and counter-productive and tends to produce sterile environments where all creativity is suppressed. So it’s doubly ironic that programming studios often seem hell-bent on actively encouraging their technical staff to give in to the temptation to produce sub-standard work in the name of spurious efficiency.
What they don’t realise is that quality and pride in your work isn’t something that can be turned on and off at the flick of a switch. The more corners one is asked to cut to meet deadlines, the more the pride in one’s work is eroded, with serious long term effects as a result.
The good programmers tend to react to this state of affairs by getting frustrated and grouchy. They either start doubting themselves, or they get pissed off and leave (often discovering in the process that the grass is no greener elsewhere). Or they retreat into their own world, ignoring both reasonable and unreasonable requests for a pragmatic approach, and become completely un-manageable.
The efficient but unimaginitive programmers thrive, because they are good at doing stuff quickly, and clever enough to layer hack upon hack and keep everything running against all the odds. There’s always a brick wall, and eventually the project hits it, but by this time the efficient programmers have made enough of a name for themselves as people who “get things done” that they are seen as the heroes. They can make a compelling case for throwing everything away and starting again, but they don’t really have the imagination or motivation to design the new version properly, thus beginning a new cycle of bodging.
The vast majority of the other programmers just go with the flow - happily pottering along and never stretching themselves or achieving their potential. They may have it in them to become great, but they probably won’t be arsed. Life is easy, they can get enough done to keep the bosses happy, and they don’t ever really have to make the mental effort to actually think hard about anything in order to do it right. It is so much easier to bodge than it is to come up with an elegant design.
Sadly these people are destined to never discover how much more satisfying it is to do things well, to come up with a really clean design, then implement it. They will never experience the pleasure of working with something that is well thought out and knowing that you are reaping the benefits of earlier planning and discipline.
More sadly still, the studios that employ these people are ultimately destined to fail. It may take years, but they will slide slowly into decline as the products that they make become ever slower, more bloated, uglier and less reliable - whilst the managers scratch their heads and wonder where it all went wrong.
There’s a petition to stop those idiots at the BBC from making their on-demand video service Windows only.
I’m going to make another attempt to do some upgrading tonight, so the web site will probably be up & down a bit, and I’m temporarily resetting the theme back to a default.
Normal service may be resumed at some point, possibly, if I’m lucky.
The short version: it’s a bit bloody hairy! I’d avoid it if I were you.
The long version:
I was running MySQL 4.0, and trying to get Django to work.
Running ./manage.py syncdb, it said “server is too old to set charset”
It seemed to need 4.1 to get some Django stuff working, so thought I’d upgrade. I’m running Drupal 4.7 on the same server, which is a Mac running 10.3.9. I was (fairly) confident that Drupal was backed up ok, so decided to just download the DMG for MySQL 4.1 and give it a whirl.
So, after installing and restarting, I tried to access my website - hello? anyone there? Oh bollocks… no website.
Looking at the /usr/local/mysql/data/ folder I was horrified to discover that all my databases had disappeared. Brown trousers time…
At this point I should point out that I am an idiot. If this happens to you, don’t panic. The installer has not eaten your databases, which is what I thought it had done!
If you look in /usr/local/ you will discover that mysql is aliased to the actual installation, for example mysql-max-4.1.22-apple-darwin7.9.0-powerpc. I didn’t realise this, and I had the directory aliased from somewhere else too, so I thought my databases were gone.
I was remarkably calm. Oh well, I said, time to discover if the backup script actually works.
I am using mysqlhotcopy to back my databases up, and I’d never had to actually do a restore (I can’t believe I’m saying that - I hadn’t tested my backups - but then testing them isn’t that easy when you have no time and no spare server). Anyway, I had no idea how to turn the backup back into a working database.
The answer, in case you are wondering, is remarkably simple - copy it back into the right place. Wow - it’s almost like using a Mac (apologies to the hardened unix geeks out there, who must be wondering what kind of an idiot I am. The answer is, I am a very technical idiot who, due to a career spent programming macs and the occasional pc, has never had to deal with any of this shit before). I love that the Mac is based on unix now, I really do. I just wish unix would catch up sometimes…
Anyway, I copied the backup back into the right place, and as luck would have it, it seemed to work.
Of course, I had to spend a while fixing up all the sql users and passwords and privileges and all of that malarky. I always forget my MySQL root password for some reason, which really doesn’t help. Lucky I wrote it down ;)
So, I had the databases back, and everything should be hunky dory. Hit reload in the web browser, and… Drupal was complaining that it didn’t have access. To be precise, it was saying “Client does not support authentication protocol requested by server; consider upgrading MySQL client”. Eh?
I rummaged around a bit, and started thinking, uh-oh, maybe Drupal 4.7 doesn’t work with MySQL 4.1. After a bit of searching, I got the vague impression that there were some problems, but there seemed no clear solutions.
Right, I figured. In for a penny… lets upgrade Drupal to the very latest 4.7 variant, that’ll fix it.
So I did, and it didn’t.
Oh so it, maybe Drupal 5.1 will fix it.
It didn’t.
Oh, I’ve found a note saying you have to go to 5.1 via 5.0. I’ll install that.
It didn’t help.
At this point I was wishing that I hadn’t started. However, a bit more googling finally gave me this: http://drupal.org/node/13977. Aha! Nothing to do with Drupal at all.
Turns out that the password format has somehow changed and you have to do a bit of mucking around to fix it. Ok, fine, I can do that. So try again, and thank something or other, it worked. The web site came back.
Whoohooo.
This is probably where I should have stopped… except that when I tried to log in to the site to blog all of this, I couldn’t. It just silently failed to log me in, and I ended up back on the log in page. What???
I had a vague notion that a similar passwordy sort of problem was perhaps occuring, this time with Drupal’s own user table, but I couldn’t get it to work and I didn’t know how to change Drupal’s own password entries with SQL. I had gone back to 4.7 by this time, but I still couldn’t log in.
I tried running the various Drupal update scripts for various different versions of Drupal, but no joy. In fact, they didn’t work because of various other permissions problems. Some of them turned out to be the fact that I hadn’t got the permissions for the database files right when I restored them.
Ah well, thought I. I’m in a right pickle now, but at least the site sort of works. What the hell, maybe MySQL 5.0 will fix it. You can tell I was feeling optimistic tonight.
So, another DMG install later, and no further on. Actually, things were worse. Drupal 4.7 wasn’t talking to the database again, at all.
Luckily it was around this point that I realised that the multiple MySQL installations were happily residing in different directories on my server, along with my original databases. This is exactly how I’d expected it to work in the first place, I’d just got a bit confused.
So, realising that I still had my original installs of MySQL, Drupal, and the original data files, I figured that I could probably just get things working as they originally were.
I did. It works.
Interesting evening that.
The only problem is, I still can’t get Django to talk to MySQL. Arse.
Well I finally managed to figure out some of the problems I’ve been having and upgrade both MySQL and Drupal.
As you will notice, the site theme has changed as a result, and it’ll probably take me a while to get things straight.
The route that I took in the end was to use mysqldump to back up the entire database, upgrade to MySQL 5, and restore the database from the dump. This seemed to work fine and left me with a working database with my existing 4.7.0 install of Drupal.
I then upgraded Drupal in stages from 4.7.0 -> 4.7.6 -> 5.0 -> 5.1, running update.php at each stage. A bit laborious perhaps, but it worked without a hitch.
Thanks to D’Arcy Norman for a handy link, which put me on the right path.