Project management notes to self

1. Panic early. Reduce features and complexity early, you can always add them later. Better than having to drop them at the last minute.
2. Clear roles and responsibilities - obvious but doesn't always happen. Who do I have to ask to get X approved...
3. Before you say no to an idea make sure you have an alternative to propose -
4. Don't fiddle with time estimates just because they are inconvenient.
5. Don't isolate yourself from critical voices.

Google Web Toolkit Blog: Look ma, no plugin!

Still not sure if a hoax.

Many months on I'm still not sure if GWT Quake is real. Looks like too much of a pig to get running to find out for real.Already my pointy haired boss has got the wrong end of the stick and thinks GWT is all about making a website look pretty.

Composition for happy ORM?

None of the polymorphic mapping strategies for ORM seem to work very well.

• Table per class hierarchy - Is too evil to mention.
• Table per class - Very similar to composition?
• Table per concrete class - Makes queries and FKs painful.

Composition seems to map nicely to relational databases. Also in the real world composition can model the world nicely.

A database is for life not just christmas

If your wiz bang framework requires the database to be in a particular style (random fields, denormalisation) then dump your framework before you contaminate your database. If your design has any merit the database should be around much longer and have different clients that don't want your rubbish in their face.

How can software be so bad?

Currently working on a database system that costs customers serious amounts of cash per year and big money for configuration. It does pretty much what the charity case management system database we wrote but where as that takes about a week to produce a 250 field database this system takes months to do something vastly simpler. It is also slow and near impossible to use. Some of it can be put down to short timescales and people without the right skill sets but the bulk of it seems to be just lack of a tidy mind. Muddling different concerns and concepts. Ah well.

database as persistence bucket

RDBMS are rubbish as persistence stores for OO systems so why is it the norm to use them? It leads to sensible people using them as just a persistence bucket. Using them as the point of integration is seen as being very old fashioned. Maybe due to their age rather than elegance the tools alone make it very attractive.

Data legacy

Nice things like automated testing means coders can relax when it comes to code structure and actual implementation but definitely does not mean we can relax about data legacy. External APIs, even for people, build up a very hard to change legacy. Even more often forgotten is the rubbish that sometimes gets put into customer databases in a hurry to get a new version out.

Seems to me it is worth being very anal and putting a lot of thought into everything that will build up legacy. Public APIs, UIs, datastores...