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?
"The segmenting of our web has to stop, especially that driven by the partisan hatred of Internet Explorer."
ReplyDeleteThe "partisan" part would be fair comment if the IE line hadn't partially seceded from the web by intentionally diverging from W3C compliance early in its lifecycle. As my erstwhile colleague @psd is wont to say "The web is agreement". When a browser disagrees with the standards ecosystem due to a bug (e.g. your "quirky Firefox" example) I think it tends to sit better with the psychology of web devs (well, they were at least *trying* to hit standards, we'll work around it). When a browser disagrees (or disagreed) intentionally for the benefit of one company devs tend to want to ignore it, or if they can't ignore it, kill it with fire - even when the company in question is attempting to turn it around, that (anti-) trust was lost a long time ago.
This, of course, is just psychology, and your point here is more about professionalism. You're saying (correct me if I'm off base): "This is the ecosystem as it is, many use the 'disagreeing' browser, which means that there's a practical implicit consensus formed by the agglomeration of imperfect software. We write software for this extant consensus, and we should not lop bits off this consensus just because we disagree with the motivation of one browser developer".
Fair enough. This is doing the best by your client. I respect that.
However, I think a lot of devs believe (however naïvely) that by putting an monetary figure on pointing out that the IE line is acting, or has acted in, bad faith, they are doing what they can for a sustainable, supportable web. I think they believe they are discouraging the sort of anti-trust practice that has led us to putting company-specific disclaimers, shims, and consensus emulsifiers in an ugly section at the top of every HTML representation they ever render.
Then again, some are no doubt gouging, as you rightly point out. I like your approach. It's practical and clients will get good value from you. However, as a web dev advancing in years, I *need* these standards to work without too many company-specific deviations. I just don't have the faculties to hold all the workarounds in my head any more. It *does* take me longer.
You can, of course, suggest I go tend sheep or whittle pine if you like :)