This post is partially related to my previous blog post about Rewind and GoRewind.

Even though I’ve been working as a full-time developer for the past 4-5 years, it still hits me how much boiler plate is required to create a proper software project. In fact, I’ve seen so many times how extra functionality is bundled into applications just because the alternative would require many hours of setting things up. This despite the fact that functionality is orthogonal and has totally different life cycles.

Some of the things I’m thinking about are:

  • Choosing a license and making sure that it is published correctly. That is, included in all source files, including my snail mail address etc. I even wrote a test for this.
  • For Python projects; setting up a proper setup.py file. This also includes a bunch of reading figuring out why Distribute should be used instead of Setuptools. Not to mention understanding entry points, test dependencies and publishing to PyPi.
  • For other projects; setting up a proper build system [3], figure out how to run tests, bundle and distribute things etc.
  • Choosing a testing platform. In my case Nose proved to be a great choice.
  • Choosing a coding standard. I was tired of messing around in undocumented code with mixed types of indentation. Both PEP8 and PEP257 proved invaluable. In fact, I took things to a new level and created coding standards tests that asserted all code adhered to these two PEPs. It used the pep8 and pep257 projects’ APIs for this. It may sound too strict, but the fact is, it was wonderful to have these automatically tested! Also, the fact that Go comes with its own formatter has proven to me that it’s a valuable direction to go.
  • Choosing versioning strategy and figuring out a branching model.

Open Source projects also involves building a community; mailing lists, contribution processes etc.

It takes time to set things up. And it’s surprising that we, the Software Community haven’t come further with some of these obstacles.