Narrowness in software

It’s a joy working with software projects, but there always seems to be half as much time available as estimated and what’s to be done always seems to be twice as much as estimated.  And that’s in the good cases. No matter how narrowly you think you’ve defined a project, it tends to fractalize.  If you can reduce at the outset — and even seemingly unnecessarily — the number of new things that have to be learned or dealt with in a project, the probability of getting it functional increases.

In the recent past, I’ve tried to stay up on a way larger number of new things that are bright and shiny than I can really deal with.  Time to toss a lot out.  Narrowness in software, goals for 2012:

  • Python 2.7.2  <– avoid diversions to learn more in Ruby, Javascript, JQuery, bash, Java, C++, Erlang, php, etc,. and put off Python 3.2+ until Django runs on it, which seems roughly one year out.
  • PostgreSQL <– MySQL.  Took a while to get comfortable in pg but seems reasonable now.
  • nginx and uwsgi <– ok, need Apache and mod_wsgi in two ongoing projects.
  • Django 1.3 <– avoid diversions to learn other frameworks, enjoy the fruits of class-based generic views in 1.3, look forward to 1.4 fixing some things.
  • Ubuntu 10.10 on laptop and 11.04 server on servers <– 11.10 still has “classic” option, though not installed by default; avoid investigating proliferating hubris of Mint, Ubuntu, non-Ubuntu UI options.
  • git <– lots of good documentation; if I force myself to use git every day I might actually start needing to consult the docs less.