The Three Day Rule

brian_d_foy on 2002-12-04T19:09:10

A post to the Perl Jobs list looks for someone to recover a MySQL schema from code. Apparently the developer did not bother to do a table dump after they get everything set up, or at least document it.

The task is fairly simple (unless they have done something really wierd). Look at all of the SQL statements, record table and column names, then reconstruct what you find, maybe throwing in a primary key column for good measure.

To do that, I need is something that sees every SQL statement. What could do that? Hmmm... DBI! I need is a DBD that records every SQL statement. Some DBDs may already do this in the form of various server-specific logs.

Once I have the SQL statements, SQL::Statement can pull out the various parts. A hash of hashes with the table names as first-level keys and column names as second-level keys should do the trick---at least I think it should.

Andy Lester reminds me of the two major problems: the program is likely to stop working when it does not get the right data back from a SELECT, and the schema may not be completely described by the code---never mind the data loss problem.

This brings me to the Three Day Rule that I have used for a while. Since this posted job seems like an interesting problem right now, I might start hacking a solution. However, will it still be a good idea three days from now? Most of my ideas cannot last the day. Good ideas will still be good ideas after a couple of days and during the interim the idea simmers in my head so that various problems have a chance to present themselves. If I follow the Three Day Rule, so that I do not start serious coding before three days from when I think it is a good idea, I optimize my coding by eliminating most of the bad ideas. I can easily mistake enthusiasm and skill for quality---just because I can do something does not mean it is a good idea and that I should spend my time on it.

Like any other rule, the Three Day Rule is only a guideline for programming I consider work rather than play, and most people cannot tell their managers that they have to wait three days to do something. I have seen a lot of projects fail because people dove into the coding too soon, and that really is a project manager's problem. As I was flipping through More Programming Pearls which has an essay titled "Bumper-Sticker Computer Science"---what we might call a quotes file today. Two of them are part of the Three Day Rule.

The sooner you start to code, the longer the program takes. --- Roy Carlson

If you can't write it down in English, you can't code it. --- Peter Halpern

When I ran Perl Mongers people volunteered to do all sorts of things, but only a handful ever did anything---and that handful did things that did not require much code (save Leon who makes those really nifty Perl Monger World Domination maps). They started typing "#!/usr/bin/perl" before they found out if they should even be typing. They got stuck on the details because they did not know where they were going.

Typing code is only a part of programming, and it happens fairly late in the process. I like to think of it as writing a high school term paper---research, cogitate, develop, outline, draft, rewrite, turn-in. A lot of bugs (and bad grades) relate to skipping the early phases. I do not have to make fancy UML diagrams or create CRC cards for everything, but I should have a pretty good idea what might happen along the way once I start typing.

In three days I should find out if this idea is any good, and I am sure plenty of people will have pitfalls to point out, which brings me to the Tell Someone What You Are Doing Rule that also saves me from a lot of bad ideas.

[If anyone takes that job and solves it using this method, please tell me about it :)]