Take Off And Nuke The Entire Site From Orbit...

...it's the only way to be sure.

In any large organization, a software kickoff meeting involves a bunch of programmers and managers in a room, staring at a whiteboard. The whiteboard starts with the words "OUR PROJECT" and slowly fills up with components of the project, until everyone's eyes have glazed over. The smart programmers in the bunch will ignore the big picture, instead looking for the one morsel of the project that doesn't seem too terribly open-ended, and proudly announce that you'll take that part as your own.

If you choose wisely, you are free to develop your component in peace, while everyone else fights off the dual demons of Unrealistic Deadlines and Scope Creep.

If you choose poorly, you have yourself to blame.

If you don't choose at all, then you're resigned to hiding underneath your desk until your you get assigned whatever component remains. It is 100% certain that this component will involve duplicating the business functions performed by Marjorie in Accounting, and you must extract her 30 years of institutional knowledge before she retires in six weeks. Marjorie won't understand why you're bothering her when she's so close to retiring, and she can't understand why you want to know that Ed The Janitor is paid bi-weekly instead of monthly. After all, it's Ed, everybody knows when he gets his checks...

Those are your options in a large organization. I am not in a large organization.

Everything on the whiteboard goes straight to my to-do list. I even get to clean the whiteboard. My eyes are glazing over, and I wrote everything on the whiteboard. I could hide under a desk, but I'd know where to find me.

So, first things first is an analysis of the applications at hand.

There's an e-commerce site. It's PHP in most places. The PHP is documented to the extent that there are header comments, but the comments do little more than mention the initial author of the code (who has long since left the organization), and the name of the file (usually wrong).

The coding style is that of somebody who was desperately afraid that the Russians might get a hold of the code it. One letter variables. Everything global. Procedures are a waste of CPU, that sorta thing. SQL queries with interpolated variables, the sort of thing that would be a gaping hole for a SQL injection attack if the means of users entering data weren't so limited.

The database itself is postgresql. That means there is hope. If it had been mysql, I wouldn't have had half the tools at my disposal, and I'd be spending all my time finding ways to join 6 tables together in a way that the query enging wouldn't vomit on me.

The SQL used inside the app is another story. It's that of someone who has an extensive background in DBASE IV. Nested loops of queries. Updating a row multiple times, once per column, in the same of some efficiency unrelated to reality.

Periodic database jobs are performed not by cron job invoking a sql script, but by a cron job fetching a web page, and the web page performs a long-running series of nested SQLs. Rube Goldberg would be proud.

In short, it is written like most applications where the team lacks a database guy. I can't complain, since I've made my living off of the fact that most programmers either hate databases, or don't understand them. Mostly, they just hate them, and pile layer upon layer of objects on top of them so that they don't ever have to look at SQL.

The website is attractive, but suffers from HTML coding standards left in the dust of 1998. That makes minor changes very hard to do without breaking the Dreamweaver-esque table layout strategy. Strategy is a strong term. I will call it the table-layout coincidence.

So my tasks are thus (in no particular order):

- Clean up the SQLs, do prepared statements to avoid SQL injection attacks and possibly help the optimizer reuse query plans.

- Clean up the HTML, making real use of stylesheets.

- Move HTML to a templating engine so that I can see the business logic in the code more clearly.

- Document each page, identifying which ones are used, how often they get used by the application.

- Document all ancillary jobs, refactor them using tools more suitable to the task.

- Add the new features that are needed on the site.

- Formalize the backup and recovery strategy. Just because backups are made, doesn't mean I can restore the site in case of disaster.

Each of these is a gross oversimplification, but my eyes will glaze over if I try to look at this all at once. I'm going to have to tackle this one piece at a time, but even trying to pick a piece is tough.

My inclination is to nuke everything and start over, except that for all its flaws, the code works. It's tough to sell the idea of replacing something that plainly works with something that might not, just because the old thing is ugly on the inside.

I decided to start with HTML cleanup. Of course, no plan survives first contact with the enemy, and this plan was no different. More on that next time.

Good luck, you're on your own, now.

Hi.

I'm a database programmer. I do all sorts of programming, but clients usually hire me to do database work, and leave the other stuff to their in-house staff.

Normally, when I have coding problems, or I want to show off a great solution to a problem, I take it to another programmer on the team.

This time, there is no other programmer. I'm it.

Also, this time, I'm a part-owner.

It's a software project like many other's that I've taken on. It was written by a third party, and though they're still in the picture, the documentation is scarce, and the code has clearly been through several programmer's hands, so it lacks a consistent coding standards...if it had them in the first place.

The application is up and running and serving users. Some are happy and some are not. The administrators of the app are also mixed. They may not like the performance or the feature set, but there's an entrenched sense that what is there now works, so anything I change shouldn't break that.

And from their perspective, it does work.

Just not from mine. And I've got to whip it into shape while at the same time fielding requests from the business users.

I don't have anybody to hear my complaints, or share in my victories, so instead I have you. Hope you enjoy reading it.