Wow. This is brilliant. Especially the sins committed, as I am also guilty of a number of them.

This has inspired me to begin looking back at my projects and compiling a similar list of things that I have learned by doing it wrong.

A refreshing change to the general level of hubris today. Thanks.

If you haven't already, check out this guy's growing treasure trove of writing:

http://sites.google.com/site/yacoset/

Many of his articles have been posted on HN and elsewhere already.

A gem from that site:

  <Shipments>
    <LineItem LineNumber="1" SKU="123456">
        <Order Number="555444">
            <Package ShipMethod="UPS" Tracking="1Z123467WW53631"/>
        </Order>
    </LineItem>
    <LineItem LineNumber="2" SKU="654321">
        <Order Number="555444">
            <Package ShipMethod="UPS" Tracking="1Z123467WW53631"/>
        </Order>
    </LineItem>
  </Shipments>

  The designer of this schema was on crack.

http://sites.google.com/site/yacoset/Home/an-open-letter-to-...

That entire article is a treasure chest, almost strikes me as he wrote it during a therapy session.

Hey what a coincidence! I dunno why he failed with the 4th one.

We maintain a leasing administration system here, and one of the most important/critical features is doing the thing he describes. You can know the exact state of any leasing contract (or a group, or all of them) by chosing a date of the future and past. That way you can compare the expected result vs reality. It is implemented fully inside a SQL DBMS (and works fine)....

Yeah, that bit made me cringe a bit too, since you have to do the something similar for storing insurance policies (track when things become effective, including forward-dated changes, storing past versions, etc.). No predictions necessary in our case. I'm guessing dealing with the time dimension is a general property of any system that needs to store anything that qualifies as a legal contract.

It is true, however, that adding in that time dimension makes everything a much, much harder problem.

Good lessons, except for 1, without doing that there'd be no Google map-reduce and Hadoop. Of course, this means you should be using Hadoop now.

Great article. It's a pity that over-engineering is often the path to failure, because over-engineering is so terrifically fun to do!

I got to the end of the entry and felt inclined to click "Report abuse" at the bottom of the page. =D

Loved it. Looking back, I have sinned as well.

@clarencewenham, you should have a nice blog and move your content there. Doesn't matter whether you update it frequently or not.

I dislike the blog format, I've tried it several times and it doesn't work for me. I found that I prefer the Wiki style where you focus on a TOC. Hopefully Google will figure out how to implement RSS for GSites one day.

Makes me think of that quote from Spinal Tap. You know, that there's a fine line...

Is there a way to access this without having to login to google docs?

an interesting article in similar vain: niklaus wirth's "good ideas, through the looking glass".