Previous Entry Share Next Entry
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...

  • 1
"The Mythical Man-Month" is a much better comment on the scaling problems you identify than you seem to remember of it. Project efficiency is always (in any field; programming is nothing unusual in this regard) higher with fewer people involved. Nonetheless, there are problems that cannot be handled at a smaller scale, and cutting staffing won't get those problems solved faster, even if efficiency is vastly improved thereby.

  • 1

Log in

No account? Create an account