Well, here we are.  A few days after I kicked off the project, and I have the main stuff I needed working:

• Publishing platform - write an article, deliver the article.
• A (crude, not scalable) indexing system - in fact full of bugs (more about that later).
• Atom Feed - I don't see how a blog would be useful without a syndication system of some sort.
• A contact form - no point in sharing with the world if they can't talk back.

Bugs, Bugs, and more Bugz

No surprise there - I'm not a good coder for stuff like this.  In the rush to get things done, a lot of things didn't get done, or got done in a way that is flaky, or at best ugly code which will probably break in the future when I change something.

Notable things that are missing / broken:

• The indexing system is very unscalable.
• It currently displays everything - no "only recent stuff" or paginated indexes.
• There is no caching of data - each page load reads all the available blog entries and parses them for information.
• Hard coded nastiness where I am trying to keep configuration to a minimum - the Atom Feed is a particular area where there is a lot of hard coded stuff to minimise config.
• There are probably all sorts of messy html/xhtml things that will appear with future use.
• The navigation panel and main index CSS is quick and dirty and needs fixing up properly.
• The CSS is still not happy where the page isn't big enough to fill the browser window - we end up with a gap at the bottom of the page.

TO-DO - more features

After fixing the bugs - yeah, I know it is more fun to do features. Fortunately I can avoid the pressures of a commercial environment where the management will be wanting the new features at the expense of digging a bigger hole by not fixing the bugs. Without fixing the bugs first I would effectively be building on crumbling foundations, but this is often what happens in companies where the up front stuff like having a stable platform, testing and fixing bugs is often compromised early on for the sake of shipping earlier. While it may work, it is often a case of false economy, especially when working on dependencies for other projects (ie. infrastructure, libraries etc.).

This is typical of the very short term view taken in many companies I have been involved with in one way or another. Funny enough the same thing has been blamed for much of the Credit Crunch mess in the banking world. After all, it will likely be someone else's problem to clear up. So why is it almost always the company founders or owners in small companies who seem to be doing this more than anyone? Having seen this in company after company, I suspect because because they have an emotional involvement which outsiders and those at the coal face can avoid. Compounding this with the problem of entrepreneur personality being at odds with management (getting things organised and done in a clean, structured manner) personality, and very often the people at the top don't trust those below to do their jobs. Admittedly, sometimes with good reason, but in my experience more often it becomes an excuse to override decisions of those best placed to make them.

So back to new features! The main stuff that I want to add now is:

• Tagging mechanism:
• People will have to type in tags - this helps avoid casual poisoning and false results from bots.
• Only the most common tags will be shown using rules something like whichever is least:
• Top 50% of tags.
• Top 10 tags.
• Some form of tag index for finding articles by tag.
• Some form of anti-abuse mechanism (eg. only one go per IP address, blacklisting, abuse links etc.).
• Some form of anti-spam mechanism.
• Statistics:
• Some form of popularity weighted index.
• Some form of link based index (eg. tie articles together by common stuff they link to).
• Discussions:
• Low friction (avoid complicated registration process).
• Some form of threading, possibly with some means of discussing linked to specific parts of the article, allong the same lines as proposed by Steve Yegge.
• Some form of anti-abuse mechanism (eg. blacklisting, abuse links etc.).
• Some form of anti-spam mechanism.
• Related Blogs - use stats, common tags etc. to cross-link postings to other related articles in the blog.
• Linked file relay - get the platform to deliver files from the article directories which will allow images and other files to be linked in the blog articles.
• Photo gallery functionality - I would like to be able to blog about something with an attached photo gallery.
• Open Source the platform.

I guess I will probably be busy for some time with all that. The reality is that unless I have a reason to do a lot of this stuff, I will probably not be motivated. Much of this will be related to be blog becoming popular and scratching my itches for stuff I want to do with it.

Oops - Spec Creep!

Ok - so I have already fallen into the trap of extending what originally (only a few days ago) started off as a minimalist blog platform. This can be a real killer with commercial projects. It demotivates the team and causes all manner of problems, but someone always finds an excuse to justify it. What I think should happen is that the features in a release should be prioritised, and then decide on how many of those features we allow in to each release. As I understand, this is one of the fundamental principals behind Scrum methodology.

In my case I'm not fussed. I am not pressuring myself, and won't get stressed about getting lots of features implemented quickly. It's very much a case of "I will implement it when I want it". Once I Open Source the project then then "code welcome" becomes the gatekeeper of feature requests.