In an earlier post I posited that the folks behind Twitter were about building a short-messaging platform that went far beyond the prosaic visage they masquerade behind.

With the recent announcement of Twitter securing venture funding there was much discussion of Twitter being unfettered by a business plan. Apologies to anyone who actually knows this to be true however for now I will remain skeptical that this remotely true. I think it would too difficult to attract the engineering talent required to get something like Twitter off the ground if the sole stated aim was to attract users and see what happened next.

Business plans are over-rated?

The VCs involved quipped about investing in a company without a business plan had worked out previously for them and felt it would again. Andrew Parker believes that companies are busy working on traction because business plans are pointless until you get some. In a similar vein Umair Haque and Paul Kredosky also reinforce this meme and believe that companies might avoid a business plan to make themselves a small target when under the scrutiny of a VC. You can’t criticize what doesn’t exist is the thinking, I guess. This strategy seems a little too transparent to me, to be effective. Actually I think I will nickname this strategy ‘the Aardvark’ (in case it catches on!) - where companies roll up into a ball so VCs can only see the protective plate-armor; their millions of users who are waiting to spend their money as soon as the company thinks of something they can spend it on.

Alright, smart-alec, where’s the evidence that there is more to Twitter?

Twitter’s innocuous ‘What are you doing now?’ query, the broadcasting of which is the key function of the service currently, offers an activity which is novel enough to generate interest in the service but is also disarming enough for people to underestimate their strategy.

Dave Winer who loves thinking publicly about these things believes that Twitter’s democratic approach to its API is part of its strength. 

Twitter’s API is very simple. It covers the entire functionality, leaves nothing out. You could implement the Twitter user interface using the API.

The openness of the Twitter API differs from many other offerings which limit functionality available via API to keep users loyal to the main interface of the respective service.

Often people cite the simplicity of things as being their strength but what I think they mean is the level of abstraction and the constraints applied. A clean abstraction is economical in its language, avoiding permutative options - those can be achieved through combining with other abstractions.

The API has been kept abstract and open because Twitter are betting on people finding applications for a short-message nexus which can find you whilst mobile, working or at home. Designing the API like this may have been a natural tendency of the engineers in charge however when viewed alongside the extensive IM and SMS gateways they are maintaining worldwide there appears to be too much shape for a company supposedly looking purely for traction.

I borrowed an i-mate to capture some small thoughts of our trip as we traveled. I didn’t write much because even with the K-JAM’s QWERTY keyboard it was pretty painful to type.

First a precious few thoughts from near the end of our flight into Istanbul. 20+ hours of travel, the second part of which, with a higher majority of Turks onboard was much rowdier than I’ve ever been used to on a flight.

We are one hour from Istanbul and the flights children are getting restless. Feels a bit like a family birthday party - a bit much after 20 something hours of travel and a full-on work day before that.

Our first challenge once we are free from the airport will be to tram to Sultanahmet and try locate our hotel. We will likely walk past the blue mosque and other locations of interest along the way but the yearn for a hot shower should stymie the temptation to linger too long.

Tomorrow’s tour should see us back there anyway but with someone who knows what we are looking at.

Later in the trip I revisited the memory of our first day and wrote a second document on the K-JAM - this time evidentially more stalwart, more determined to capture my thoughts…

Arriving in Istanbul airport saw us stumbling around until another traveller, a german I think, confirmed our feeling that a visa was required. No trouble, they are purchased for 20 lira right next to immigration.

A wait in a throng of european tourists and then we were through hurtling into the airport, bags arrived at the conveyor belt just after we did and so after all that flight we had slipped easily into Turkey without a hitch. A friendly Turk at the info desk pointed us to the metro and showed us our line and changeover on the map.

The metro is modern, efficient and runs on time. We experienced a brief amount of confused delay at the changeover as we searched for corresponding names on our map but nothing too stressful though as it was still mid afternoon and the weather was perfect and we were soon on the correct tram to Sultanahmet.

From the Sultanahmet tram stop you could spy the minuets of the Blue Mosque. To welcome us, it almost seemed, the prayer song began to ring out from the speakers placed atop each of the mosques towers and we were drawn towards it like argonauts to the sirens.

The clerics voice was alternating from tower to tower to create an omnipresent effect and did I mention it was maddeningly loud? Deliriously tired by this point and knowing we could only be not more than 100 metres to our hotel it became impossible to think clearly to determine how we could locate the small street our hotel was located on when the map we had did not name small streets.

We decided to sit and wait the cleric out in the beautiful warm environment however when it was obvious the cleric had much puff and as far as we knew might continue throughout the afternoon we started looking for other maps. Found them - covered in calamine lotion of course. Note to self; carrying containers storing liquids in a plastic bag is always a good idea. Try do that next time.

Hotel found, only a step or two off the main street we were quickly checked in and up to our room, remembering too late the guide books advice to tip the bag boy. Exhausted we soon were snoozing. I woke a few times feeling guilty we were sleeping through the end of what appeared to be a stunningly beautiful day in Istanbul but the exhaustion of 40 waking hours won out.

Well that feels good to have got that to print (its been trapped in the phone for weeks waiting for my rescue). I hope to follow up later (probably days, hopefully not weeks) with more fragments of my trip and a few photos at some later point as the trip for me was quite perfect and magical.

A point I covered in earlier posts about Twitter which I would like to revisit is that of Twitter’s usefulness being less about letting people know ‘What I’m doing now’ (which, as readers of this blog may remember, I don’t find that useful) and more about it as the nexus point between various gateways.

Reviewing what I said in one of the earlier posts :

Something I haven’t heard much in the current conversations about Twitter and that I think is important is that one of the key strategic strengths of the service is infrastructural - the link between IM and mobile network messaging and the web is a useful one which many applications will build upon. I think one of the players in the industry, whether Twitter or Jaiku or a new player to come (and regardless, likely to be acquired by one of the big companies) will benefit from owning a reliable set of gateways maintaining these links.

Being a platform is hard work

As anyone using the service would have noticed - its hard work maintaining gateways and services and in general ’being the platform’ or nexus point for a variety of different consumers.

Some proof of this; another company, IMified who are in a very similar business to Twitter, recently plugged Twitter into their own service whilst the Twitter IM bots were out of action to allow users of Twitter to keep on Twittering :

Over the weekend we added Twitter as a new IMified service. We definitely feel their pain trying to keep an IM bot up and running. We’ve had our own issues in case you haven’t noticed ; )

And this cheekiness :

It appears the Twitter IM bots are still down, but have no fear, we just added support for notification updates to go along with the release of status updating last week. What can I say, we’re opportunists!

But being a platform can also pay off…

One of the coolest bits of functionality that’s actually useful that Twitter has afforded another service I use, RememberTheMilk, is the ability to use the SMS and IM gateways to post tasks to my task lists. This saves me money and time when I am out and about and I think of something I need to do/remember.

A ‘QuickAdd via SMS’ option to Google Calendar should be a straight-forward (and bloody useful!) addition  if utilizing the Twitter platform. I am sure a variety of other services leveraging SMS/IM will appear (Google/Yahoo/MSN Search?) benefiting from the effort the Twitter people have undertaken to ensure the infrastructure they provide stays accessible (and I am not saying they are there yet…).

If I make bold (and possibly long) assertion; assuming people continue to find use for these short message/short instruction services and the Twitter team can keep it all hanging together, ironing out the kinks and interruptions, we will see them become the platform of choice for short-message-in/short-message-out type services and in the acquisition path of a multi-national telco!

Anyone who has worked at an organization with more than a few developers for a reasonable period of time would have felt the pain associated with a growing codebase. The word ‘legacy’ creeps into the everyday language and the number of maintenance tasks soon exceeds the amount of time spent writing new code.

The maintenance tasks hopefully make your existing clients happy (’serve the client in front of you’) but the reduction in new code generally means less new features per developer and therefore is naturally linked to a reduction in your ability to increase the amount of product you can sell to your clients.

There is of course a correlation with the amount of code you write to the amount of maintenance it requires however exactly to what factor this is depends entirely on your processes and how they affect the technical debt you incur.

Relish deleting code

My first piece of advice to any developer (you never know when your own codebase will become a multi-developer maintenance monster) is to relish deleting code. Most code, after-all, is the application of standard algorithms and patterns to specific problems and is therefore not that useful or unique once it is no longer required.

Don’t keep code around just in case. You have it under version control so as soon as it is orphaned then delete that sucker. Have an active deprecation process that is regular and ruthless!

Campaign actively to deprecate unused functionality within your organization as well. The temptation to keep functionality around just in case is not reserved to developers; product development, sales and marketing all fall into this trap.

It is costly to leave unused functionality and code intact because it costs an organization in a number of ways:

• Developers have more complexity to deal with and this will always result in waste.
• Users have more unnecessary complexity which affects the usability of your product which in turn affects how your product is percieved.
• Technical debt is incurred over time - its like continuing to pay rent on an apartment you already moved out of.

The global namespace is not your playground

Making changes becomes the focus well before the codebase even reaches the inflection point of maintenance outstripping new code. This is because many features of any given software product are built on top of existing features.

The enemy of change is the dependency and the easiest way to create unnecessary dependencies is to create globals because if its in the global scope then other coders will use them. Declaration scope and JIT inclusion of necessary dependencies are your friends - use these wisely.

Those entry points into your codebase that are necessary because they are utilitarian or because they kick your application off should at least be namespaced off into a structure by using a pattern such as the Singleton. Don’t be fooled - a Singleton is still a type of global but it is much easier to attach documentation to and control the signature for it.

Divide your code into layers to assist in reducing coupling and avoid having lower layers called directly from layers that are not immediately above them. For instance - if your page or front-controller calls your database directly you will find you reimplement the same query creation code, query execution and object population code over and over. Its much better to abstract this functionality to an object hierarchy which can specialise in these tasks as there is nothing useful in seeing lowlevel logic scattered through-out the logic behind your presentation.

Much of this advice is available from a variety of sources and I do recommend reading up further on the topics I have mentioned if you found that some warning bells with your own organisation’s codebase started to ring. Codebases can become massive - particularly when their are multiple developers involved multiplied by a few years of time. Some continual investment in keeping the house clean will pay off by allowing you to spend more time on new code.

I think my recent reduction in post frequency, whilst mostly due to various events in my personal life, has been somewhat affected by growing frustrations with my authoring tools.

As I’ve previously noted, I was using the performancing.com firefox extension for authoring my blog posts. Its since renamed to Scribefire and had a few improvements however in the end its just not pleasant to write into an area that is a third of your viewing area. You can expand it however this makes the reason you would use a plugin for authoring reasonably redundant.

Browser extensions - particularly firefox ones can seem a touch sluggish and I assume this is because they are mostly interpreted javascript.

I also did a few of my posts in the editor interface provided in the Wordpress administration area. Its okay for last minute edits and applying of links but in general its got a few niggling issues with the editor that you constantly come across.

Time to scout for a standalone, hopefully native application for authoring. I thought I had seen one from Microsoft but decided to Google around anyway in case there was something out there that was widely regarded as the preferred post authoring tool.

Windows Live Writer appeared in the results so I figured I may as check it out as it was a free download and of course would be a native windows application.

A painless install later and I was up and writing my post. And now this one. The interface is clean, attractive and simple. The editing area is presented like a blank sheet of paper which seems to beg for words to be entered into it.

If your OS is windows and you run a blog, I recommend checking it out.

There is no denying that feature-wise Wordpress offers everything that an amateur or even a professional blogger could need.

Unfortunately, something I always suspected of WP but never wanted to admit was internally there was a level of chaos which might spill out and hurt me.

Well last night, hurt me it did. I am not sure whether an edit to the theme, a new plugin or a recent upgrade was responsible but I noticed the feed was no longer validating and various applications were having trouble with this including Feedburner.

Feedburner’s FeedMedic led me quickly to discover an errant white space at the start of the file.

Familiar with PHP as I am I thought that following the execution logic from the index page (to which passing a parameter would yield the feed to be returned) should eventually locate the mischievous white space.

The first few files seemed straight-forward and single purpose however the more I dug, the more apparent WP’s internal discord became. Globals, functions everywhere (including a whole stack in a file called ‘functions’), procedural code and the occasional class that of course gets instantiated into the global namespace.

After about an hour of checking through the end of php files trimming white space and double-checking every echo I could locate I decided to take another tack. I tried to create a simple file which just recreated the variables I needed for the feed file to work.

This work revealed a very deep hierarchy of requires - as I added in one require it would require further dependencies which as I proceeded seemed less and less relevant to the work required to render the feed.

Finally I realized that WP was not going to let me debug this issue in any sort of reasonable time (without setting up a step debugger or retracing my steps earlier with echoes until I located my space) and I should just accept that a space was being buffered and I should try clear it just before I echoed my feed.

Some quick research on php.net and the only function which looked like it might clear the default output buffering php uses was ob_clean. I’d always thought this would only apply to output buffers I’d explicitly setup but it seemed to do the trick for my feed.

So what to conclude from all this?

I believe blog software will continue to evolve - but I wonder whether Wordpress be able to keep pace with all its technical debt?

That a space can break an application is somewhat of a flaw in PHP. (Using a template system with PHP helps avoid that regular case of unwanted output creeping in after a close tag.)

That it took a few hours to get a resolution on this issue is a critical flaw with Wordpress. Whilst this doesn’t seem to have hindered what appears to be the healthiest plugin support of any blogging platform I feel it will ultimately limit the competitiveness of Wordpress as better architected solutions which can foster a dedicated plugin development community similar to Wordpress come to the scene.