Tuesday, 8 January 2013

Supporting IE7, that'll cost extra?

Netmag have highlighted some developer survey results that have a frankly shocking (to my eyes) statistic... 42% of devs surveyed charge extra to support IE7!

I have a real thing about this kind differentiation, I don't like it and don't think it's very professional. While I think it's a natural and practical step to say that it becomes cost-ineffective to support certain browsers, while they are still very much viable entities we should, as standard, support them.

Factoring how much work you will have to do in testing is naturally a good thing to do, as long as you're not charging money for your own lack of competence and the time that adds to the project. However charging a certain amount for a project and then up-scaling it by X% or by adding an amount of money on is...well...it's the kind of thing EasyJet do, and we all know how we feel about that kind of practice.

When we stand back and say things like "IE7 will cost extra" we sound more like dodgy plumbers (as opposed to the very nice and ethical ones) than professionals. What do we mean, IE7 will cost extra? Are we not in the customer satisfaction business? This doesn't mean our client, of course, it means their customer! By having bolt-ons for things like IE7 we are trying to dissect and modularise what should be the very standard level of service we provide.

When we cost work we have to be realistic; we deserve to be paid for our time but at the same time the client doesn't deserve to pay for you to learn your craft. They can happily go somewhere else where someone is already an expert and can do it better and quicker, if only they knew where to go. If it's going to cost a certain amount to deal with modern web complexities then be respectful to yourself and to the client. Explain the cost and why that cost is there.

The segmenting of our web has to stop, especially that driven by the partisan hatred of Internet Explorer. We are entering a world now where changes to what our web browsers are capable of are changing every month. In less than a year we are going to start seeing reports of website that are "not working" because someone has turned off their automatic updates and is only 12 months out of date on their browsers, but the tech being requested was only implemented in vendor-specific form after that.

What do we do then? Charge for testing in Chrome 23.0.1 or earlier? Anything over Firefox 17 is ok, but below has a surcharge?

In an ideal world the conversation about what the site will be capable of, and the difficulties that could present themselves, you should have around the planning stage of the project anyway. If the client starts to get horrified at the time or cost that a particular functionality will take to complete then that is the perfect time to refine the goals, and for you to be immediately on hand with all of your knowledge and skills to come up with a new, simpler, and more palatable solution for the them.

The reality is that we will have to accept our job will cost as much as the functional spec adds complexity, and regardless of the job we should be applying an architecture that allows the site to work (where it is possible) on the weakest browsers and enhancing itself as the customer's browser allows. Do this and you'll never have to worry about fiddling about with complex invoicing, and your work will stand the test of time too. Doesn't that sound more interesting, and a little less "douche" like?