Ok, maybe ‘grand’ is a bit much. For a long time now I have wanted to blog a project. That is blog the progress of working on a project from initial concept all the way through to the completed result. I wanted to do this for the old PyCon website, but the time pressures for that work did not allow for it. I have yet to write one line of code, or create the code repository, or anything; though I have been doing continual research for the past eighteen months. To be honest I have no time for this new venture, and no way on earth do I have time to blog it. I will be spending twice the time blogging it as coding it. Thus this is doomed to failure. But that is part of the point.

The point is not to watch as some ‘master’ weaves a new project and does things in the ‘best’ way. It is not for me to impart some special wisdom. Oh, no… The point is for me to fall on my face. Hard. Repeatedly. In full view of everyone. When I see something done right I rarely learn anything from it. The most revolutionary concepts often go completely unnoticed because they just work. And no one remembers things that just work; until they don’t. So this ‘Grand Experiment’, I hope, will fail many times over.

Another reason why I have not done this before now, is that I have not really had a project which will work with this concept. Oh I have some small utility projects (django-app-plugins chief among them) which desperately need my attention, but I am not actively using them for anything. I have found that when you work on a project like that without an actual site using them, something driving the development, you end up having to envision how you would like to use it. Then when an actual use case comes up it does not quite fit what you thought you might use it for. So this is going to be driven by real use cases for a mission critical application which will be used by a small development team.

How the blogging will work.

There will be an introduction (i.e. this post), background post, big picture post, and then breakdown posts. the breakdown posts will cover the work as I do it. There will be no overarching organization beyond whatever I have had time to do and get checked in. The breakdowns will cover the work which was done in the interim commits, and or new use cases. Each use case will also include research done on options on implementation details. Things which do not work will be highlighted. Even things which do work will not work perfectly. The entire reason for this project in the first place is because nothing in existence works well enough.

So why now?

Good question self. Well there has been a pain point at work which keeps coming up. I have a mandate to specifically NOT work on this. I also am on vacation, and have not done any programming for me. But I have seven days, a wake, a funeral, games night, home owners association management company migration, PyCon issues, three parties, two kids, and a none to happy wife. Did I mention that I do not have time to do this?

So why blog it at all?

Another good question self. Because doing this in public will produce better code. At the last Django Meetup it was commented by someone unnamed that they produce much better code when it is open sourced than when it is done for work, or just to scratch that itch. Everyone present agreed that it was the case for themselves as well. And finally, by doing it this way, it is clear that while this project may end up being used at work, it is done by me, on my own machines, on my own time, and is completely tangent to technology my company cares about. It is related to another piece of software which my group at work is already open sourcing. Oh and the entire falling on my face thing… that is just too much fun to pass up.

So what is it?

It’s a bug tracker.

Wait WAIT!!! come back… don’t stop reading!

The background and overview posts will go into the research behind all the alternatives, and this project will be more about leveraging existing technology, extending existing projects, writing the few apps which are needed to fill in little bits, and more than anything else, gluing it all together. The emphasis will be on the use cases and work flows which our group uses and dealing with less than enjoyable requirements. I do not even know if this will be used by my group at work in the end, but that is not really the point after all. There is going to be sphinx, django, jquery UI, rietveld, Perforce, DevTools, and much, much more. I was told specifically not to work on it; which has almost the same effect as telling me something is impossible.