Tonight I came across an update from the IE team. This topic was also covered at A List Apart. Its best to read those articles first – its on a key Web Standards issue (short version: to trigger ‘standards mode’ in IE8 a new meta tag will be required on your pages) and I think a thorny one.

Sometimes you read something and instantly you feel that something is awry. I wasn’t alone either (although the author the esteemed Eric Meyer comes out with support for the solution):

As I read through Aaron Gustafson’sBeyond DOCTYPE: Web Standards, Forward Compatibility, and IE8, my immediate gut reaction was deeply negative. The version-targeting mechanism Aaron described was just wrong, completely backwards, the exact opposite of what we ought to be doing. Every one of my instincts, honed over a decade-plus of web development, was in opposition.

I should begin by saying – I am not one to bag all things Microsoft – I think too many people anthropomorphize companies like Microsoft and Google. In this situation however my gut reaction is to disagree with their proposed solution because it feels like yet another complication is to be added to publishing web content.

The burden of majority market share and a user-base of many millions is certainly something that will throw all sorts of confusing considerations into their pathway and thus I expect some missteps along the way (as I would from any organization).

The great thing about having the IE team blogging however is that there can be dialogue with the community and the best pathway can be illuminated through that dialogue.

The aspects that I feel are wrong about IE8 requiring a meta tag to enter standards mode are :

• The list of things developers need to do to accommodate for IE grows again.
• It feels like we are forced to trade an extra meta tag to get IE to behave.
• The article argues our mothers will have IE8. Maybe our Mums can wait for IE8 until the sites on the web incorrectly accommodating for IE7 are corrected? I implore you – ask your Mum about IE8 tonight – let me know what she says.
• I don’t like documents ‘knowing’ about what renders them.
• Something Mum once said about putting your best foot forward.
• IE9 will require a golden key embedded in your page to unlock its level 23 rendering engine.

The weird thing is I do like versioning things – we use versioning as a safety net – much as its being proposed for IE8. I guess it just doesn’t feel like the web I know. I like the idea of browser companies trying hard to render my site correctly rather than me trying to test and code for all the browsers out there.

I hate reading posts of dissent which don’t provide alternatives so here’s my hastily constructed one; Rename IE and no longer use any trace of that name to identify it.

The existing web with IE specific code only kicks in for IE. The new branded browser from Microsoft ditches the older rendering engines – drops its weight and runs like its a new entrant to the market.

Anyway, I note it here; I disagree.

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.

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.

Coding Horror covers some general criticism of Javascript libraries reminiscent of a few criticsisms I eluded to in previous posts such as “Javascript: The Quickening” and “Yahoo’s YUI Drag and Drop Module”. I think it could be stretched to other languages as well however as javascript has been a focus of mine recently (and many others) I thought I would explore some frustrations with working with the YUI library (as well as some other libraries) I have had recently.

Firstly, a point in reference to the Coding Horror post. The veneer of documentation can be a trap. The YUI library has more documentation than most, including API documentation, general overview documentation, cheat sheets and many examples. All of that and seasoned OOP javascript developers can still find it quite difficult to use parts of it for work more complicated than the basic examples provided in the documentation. I am interested in exploring why this is.

I find that many examples are often not coded to a standard that would stand up to much scrutiny except somehow examples seem to be exempt from quality control. Procedural code seems to be generally preferred ‘to keep things short’ and they use short cuts such as inlining everything in your HTML which ignores the real issues that go beyond stitching a few API calls one after the other.

The more complex issues in using libraries to solve complex problems are ignored. Trying to get javascript libraries in particular, playing nice with other code can be difficult. Controlling when the code is called and when things occur are complex issues however looking at any Prototype examples you may think that randomly pasting script blocks throughout your code is a sane thing to do.

Another issue I find YUI and most other JS libraries have is not all files clearly state which other files they are dependant on. This appears to be because such documentation is not uniformly enforced across the library (This is a feature of single author libraries as well, I find).

With Javascript unable to natively define explicit dependancies it is more likely to fail with an obscure error or worse still run but incorrectly. It is a time-consuming practice to work through finding all files it may need from the library and all assets it may be relying on (CSS, images etc.). And generally nothing works at all intended until you get it just right… Javascript in particular is often dependant on the order of the includes as well.

To my mind, dependancy tracking is a key facility of documentation whether it be derived from package names or calls to ‘include’ type functions (see my earlier post for the blurred line between documentation and code).

The namespacing efforts of YUI and Dojo; and Dojo introducing linkers and the ability to dynamically include required scripts we may see this improve but until more mature solutions exist we are doomed to some very frustrating hacking – contributing to the mug’s game that is web development at the moment (a topic for a separate post).

The line between code and documentation is blurring with the introduction of regimented documentation standards. In PHP reflection (and likely other languages as well) you can use reflection to programmatically access documentation blocks meaning you *could* make code dependant on information in your doc comments! Scary!

More scary is that I discovered this via a colleague who was considering using this. You could argue it conforms to the DRY principle because we were looking to add more strict control of return types implemented in methods that are derived from an interface we defined. This would require us to redefine information already part of our doc comments should we proceed without the reflection API.

For now we have elected not to proceed because it violates the rule of least surprise. Developers do not expect edits to comments affecting code conditionals and thus our effort to enforce correct use of interfaces could backfire causing exceptions in classes implementing our defined interfaces.

At some later date when the trend has continued and there is no line between code and API documentation or at such point we are confident our unit testing will prevent deployment of exceptions due to incorrect documentation we may reconsider this approach.

I’ve been using the mostly cool blogging firefox extension by performancing.com for at least 8 months now. There are a few irritations I have with the editor however for the most part these are issues I have with many formatted text editors out there (for instance when linking some text there is no obvious way to stop applying the link formatting – I always have to apply links last to get around this) so I am forgiving on these matters.

What I occured on Friday though was more than irritating, it cost me a detailed post. I was linking for somewhere to paste the links I was collecting for pasting on text once I finished drafting my post. I remembered a ‘Notes’ tab in the Performancing editor and thought I might be able to post it there. That would be conveniant. I saw two example “Notes” in there and clicked on one to see where it would let me input my Note. The text in the main editor was replaced with the text from the Note. Neat! I thought, I can switch between my draft and my notes right here in the editor! Now, how to switch back to my draft? 30 minutes of hunting around the interface and the forums brought me to the slow realisation that my work of earlier in the day was lost.

Why name something destructive with the innocuous title of “Notes”? Why not warn of non-obvious, destructive behaviour? The irony is that I am now using this feature to protect me from an event like this – I just have to remember to click ‘Save as Note’ first or suffer a similar event. I am, of course, now in the market for a good blog editor which will combine well with my web browser research on a single screen (for when I am using the laptop free of my second screen).

My silver lining is that events like these help create a stronger usability movement.

A new version of my original post is on its way – its taken a few days to build up to retyping it.

Over time it is natural for any marketing department and development team/s to drift apart. I suspect it is often due to differing personality types amongst the decision makers – in development you often have ex-developers in management positions, in marketing you have a wide array of PR professionals and the more dangerous variety, marketing degree graduates ignoring everything they learnt in their marketing degree.

Many web developers have some marketing experience in their past – many web roles are about executing on marketing strategies – many more are multi-skilling producer/marketer/developer type roles (I’ve had experience in both).

Developers work well as marketers for certain tasks – particularly the measurable ones. Internet PR, SEO, SEM these are all tasks often undertaken by developers when there is no other implementers available. We also do some tasks terribly. Sometimes over-estimating clients and prospects. Sometimes under – we forget that they are not us.

A good marketer has been trained in all the tools and techniques to find out who the target market is. I often get frustrated when marketing lose sight of this and spend too much time engaged in PR activities (but maybe that will be the topic of a future post).

What is often overlooked is that the worst situation for a company is for communication breakdown between tech and marketing. Take the new site that one of the big 4 australian banks, ANZ, launched – designmycard.com.au. It went live with a TVC campaign – the purpose of which was to drive consumers to their website. The website is no doubt the hard work of some creative individuals as are the TVCs. The key point of connection is the URL. The ads use the more modern looking URL sans the www. So why the hell hasn’t anyone configured the webserver to resolve said domain??

As someone with a web development background I spotted the gaffe straight away and adjusted the URL I typed in the URL with the www added (after checking my internet connectivity and a host of other common issues that cause a site not to load…). But I can guarantee that the majority of people who saw the ads tonite and tried the URL did not. As Seth Godin says, ‘no one cares about you’ (that’s you ANZ).

The implementation fault is obviously on the technical side – its webserver configuration most likely. But the real fault is that a TVC campaign was launched directing people to a non-existant address. This sort of oversight I’d wager sits on the other side of the fence.

But the point of this post is not to gloat. I say wander down to your marketing manager’s pod or office and get reacquainted.

What is going on here? Technorati have listed www.statcounter.com as the #1 blog! Technorati was my source for blog rankings but how can I trust a source that lists a non-blog as #1!!

Update:

They appear to have resolved the issue. I’ll be interested to see what the explanation is…