Corporate programming: Welcome to Annoyance

I can't name the names, or I (and the company I work for) would probably be sued. And no, if you contact me, I can't even warn you: sorry.

So there's this project at work, and it costs a bundle to get done. Much of that is just figuring out requirements, as nobody (of course) really knows ALL the little details of the job. What IS clear is that there are something like 4 different spots where the same data is printed out and sent to another set of folks for data entry, so any automation at all would save a LOT of time.

I won't detail the ridiculous nightmare that was the going live with a consultant that screwed up the final production install: I mention it only because it's what got ME involved in this thing.

See, once I was brought in, I also got the following bug reports... and there are a few. But the BIG killer is the speed... or lack thereof. It's application-wide, that clicking from one page to the next is taking, roughly, 30-60 seconds. Or more. This is not a web-based content management system: this thing is just showing a list of people, and a few bits of data about them. There's no reason in the world for this nonsense.

With my time constraints, though, we bring in another consultant. And he looks at the code for a few days, and he comes back and points out that, for any given action, the application is getting THE WHOLE SET OF RECORDS in the database, then filtering them, then creating little objects for the bundle. Which all die, of course, at the end of the page hit.

This weekend, I replaced the overly complex visual basic objects with plain old ASP code and reasonable queries, and the average time is 2 seconds from one page to the next. Since I'm an open source advocate, and haven't ever worked in ASP, the fact that I can do this in a few hours means anyone who is seriously PAID for this should have never, ever done something as stupid as grabbing the full database, and certainly not making objects for all the records.

The company's DBA and I (I'm technically the webmaster, but basically I'm "that guy who can code in a bunch of languages and knows basic SQL") have asked the boss in the future, to let us be in on the approval process for any project. We'd have spotted, if we had been given the opportunity, the following danger signs:

1. No foreign keys, no constraints on the database: "that just takes away flexibility" (!!)
2. The aforementioned grabbing of all the records in a table
3. The extreme overuse of objects.

Number 1 is a giant sign of an amateur at work. By trying to be more "flexible" with the database, you

• Make it wholly possible that corrupt data can get into the database, requiring manual intervention to get it out.
• Have to do all the constraint checking and foreign key relationships in code. News flash: the folks who wrote MS SQL server, Oracle, PostgreSQL: these folks are smarter than you. Trying to do what they've already done is a waste of time, and if you're a consultant, a waste of money.
• Hide serious bugs in your code, related to "corrupt data" above: if the database has constraints, it's like a whole little set of asserts or unit tests that your code has to deal with. If your code can't, and the constraints are proper, then you have a bug. If there are no constraints, you have to FIND that bug, which is always more work.

Object overuse is endemic in modern programming. Folks, when you have a table, and you want to list that table on the screen, making a little object for each row, and calling the object display portion to show it, is only useful if you know you're going to use those objects again, a lot. In almost every case, start with the simplest piece of procedural code that shows the table, and you'll have saved yourself a LOT of work. If you really do need the objects for some future project, they'll be easier to implement well for that project AND the previous one, if by some miracle you actually need to change the old one. Probably you won't. Don't bet against your time that way.

This doesn't necessarily apply to new languages that are meant to be object-centric. In C#, it might make more sense to start with the OOP approach for your simple table display... I won't bet on it, not having gotten into C# yet, but it might.