Steaming Right Along

There's nothing quite like an involving software project to completely mess up your sense of time. For instance, I keep having this sense of, "OMG, I'm way behind, nothing's getting done, I'm going to blow all my deadlines and The World Will End".

This is why I keep a detailed Work Diary. Said Work Diary just pointed out to me that I actually started *writing* Querki on November 5th -- slightly over two weeks ago. In that time, from a standing start of not having used most of the technologies before and spending five of the intervening days mostly working on house and estate, I've gone from the initial "Hello world" to being able to log into a system with an acceptable-looking UI, creating Spaces and Things on the fly, and storing everything in a more-or-less real database. There are some cheats here and there, but by and large this is the first draft of the real, production-grade code. At most companies, that probably would have taken me six weeks.

Okay, less panicked now.

Working for myself will have its downsides, but in terms of raw coding speed it is *such* a win. It is very, very dangerous to be the architect, project manager and product manager all rolled into one, but it's astonishingly efficient. Simply by dint of not having to hold meetings, I think my code productivity is close to twice my previous personal best. And while it will undoubtedly be broken in some ways, and need fixing when actual people begin to use it, I'm not sure that's so different from the reality of most 20-person projects.

I wonder if anybody's done any formal studies of the Mythical Man-Month in recent years? It's completely obvious to me that most software projects are much too bulky -- over-staffed to the point where they are *less* productive than they would have been with fewer people, because of the communications overhead. (Roughly speaking, this overhead goes up more than linearly as you add people to a project, so it becomes overwhelming after a while. Anecdotally, efficiency starts to really suffer beyond about ten people.) But I don't know if anybody's tried to quantify the effect yet. Hmm...

Singleton tags?

Okay, here's a question for thought and discussion. I'm currently designing the Tag feature. Every Thing in Querki can have fields that are "tags", in the usual sense -- they contain whatever short text you would like. Tags will be hierarchical (because that is sometimes useful). And here's the interesting question: should tags *always* be multi-value?

One of the great failings of older databases is that they tend to be single-valued -- you can have only one Author for a Book, and such silliness. The real world is typically much messier, and that's reflected in the fact that most modern systems use Tags as sets of values: you can generally have any number of tags for a given item. Tags are remarkably powerful, and I expect them to be much-used in Querki.

So I'm clearly going to implement TagSet. Is there any reason to have a data type that is only a *single* Tag? The engineer in me says that of course such a thing should exist, since conceptually it's obvious, but the UX designer in me says not to, since you shouldn't expose a concept that is always a bad idea to use.

Opinions? Are there non-strawman cases where you would specifically want to only allow a single Tag on something? Or is it more bother than it's worth to expose this through the UI -- should I just have TagSet as the type that you always use?