Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree. The assumption here is that the corporate IT mindset is the constant factor, and Mozilla, Chrome, or whatever, have to adapt to it.

I don't agree with that assumption. Corporate IT has to get better and faster, or they will get marginalized by cloud hosted solutions that can move faster and deliver superior experiences at better cost.

If your internal software is so crappy you can't upgrade your browser, maybe you should try and fix your internal software.



> Corporate IT has to get better and faster, or they will get marginalized by cloud hosted solutions that can move faster and deliver superior experiences at better cost.

That's easy to say when you're not responsible for a system where an hour of downtime comes with a seven-figure number in brackets on this quarter's review.

Corporate IT guys get a lot of grief about imposing picky rules and making life difficult, but the bottom line is that they are the guys who are going to take the flak if stuff breaks. Most of these policies are not there because someone at the head office wants to throw their weight around, they are there because a lot of people on the corporate network really could cause serious damage without even knowing how or why if left to do whatever they wanted.

If you want to blame someone for this cultural problem, blame the big software and infrastructure providers, who haven't yet collectively invented a robust global IT architecture where risk can reliably be localised to the user at fault. Or step up and do something about it and get very rich, because it's a real problem facing literally billions of staff every day.

Alternatively, you could take the view that cloud computing is the way forward, releasing a new browser every three months will make these sorts of problems go away, and everyone who develops in-house tools and operates a conservative IT policy is a moron with no idea how to run a successful business. Good luck with that. :-)


> That's easy to say when you're not responsible for a system where an hour of downtime comes with a seven-figure number in brackets on this quarter's review.

In particular if you have such a critical system, you should have a plan on how to upgrade, test, and deploy it.

Releasing a browser every three months (or constantly, such as Chrome) does make a lot of problems go away. And having reasonably-well written web apps does help as well - just because you're developing in-house tools doesn't mean they have to suck and only work on IE6.00.14.13 patch level 3 with the right fonts and ActiveX version installed.

Corporate IT can learn a lot from how application development works on the web, the web is the more robust IT architecture you're asking for.


> In particular if you have such a critical system, you should have a plan on how to upgrade, test, and deploy it.

Indeed, but wouldn't such a plan start with building on a firm foundation that isn't going to get EOL'd and no longer support security updates after three months?

The reality is that building on FF or Chrome now means trusting potentially critical business functionality to an outside group you can't control with a history of pushing breaking changes.

(If anyone is about to pipe up with how they only release useful changes and the community testing is sufficient to prevent regressions, please keep in mind that both Firefox and Chrome have each outright broken both cosmetic rendering details and basic functionality recently, in minor/point releases that you wouldn't normally expect to change user-observable behaviour at all, plus of course there are many widely and less widely reported compatibility issues.)

> And having reasonably-well written web apps does help as well

Don't tell that to anyone who uses Java applets and has spent significant time over the past few months working around the repeated screw-ups made by major browsers as they implemented new internal details.

(If anyone is about to pipe up with how Java applets are yesterday's technology and browser vendors don't need to care about them any more, congratulations, you are a walking example of my point.)

> Corporate IT can learn a lot from how application development works on the web,

Or web application developers could learn a lot from corporate IT, depending on your point of view. Personally, I can't remember the last time I saw a business critical corporate IT system completely fail or a major deployment of old-fashioned desktop software block a whole company, while I see the trendy style of rapid-development cause major errors with alarming frequency. That applies to everything from Reddit falling over every ten minutes to Google Docs' seeming inability to display even basic documents and spreadsheets properly on all major browsers at any given time.


> Indeed, but wouldn't such a plan start with building on a firm foundation that isn't going to get EOL'd and no longer support security updates after three months?

Why? Why does it matter if 4 is EOL when 5 is available? Instead of obsessing about having security updates, why not just expect updates. If you're willing and able to test and deploy a new browser every 3 months, what does it matter if they call it 4.2 or 5.0? Test and deploy the new browser and stop worrying so much about the version number.

> If anyone is about to pipe up with how they only release useful changes and the community testing is sufficient to prevent regressions, please keep in mind that both Firefox and Chrome have each outright broken both cosmetic rendering details and basic functionality recently, in minor/point releases that you wouldn't normally expect to change user-observable behaviour at all, plus of course there are many widely and less widely reported compatibility issues.

So don't deploy on day 0. Breaking changes can be, and sometimes are, introduced in minor version increments. If you need to test, you need to do so whether you're going from 5 to 6 or 5.1 to 5.2.


> If you're willing and able to test and deploy a new browser every 3 months

I'm not, and I don't think a lot of other people are either. The version number is irrelevant. The frequency of releases is the problem here.

> So don't deploy on day 0. Breaking changes can be, and sometimes are, introduced in minor version increments.

OK, fine, but now everything is effectively a minor version increment in Firefox and Chrome, and anyone who doesn't update within 90 days is apparently going to lose all security updates. That is not a viable combination for any users who value a stable platform they can build on more than cutting edge toys.


> I'm not, and I don't think a lot of other people are either. The version number is irrelevant. The frequency of releases is the problem here.

A lot of people very clearly are willing to update every three months. A lot of users update Firefox regularly. And for people using Chrome, they get updates even more frequently. When the upgrading is painless, no one minds doing it.

As for corporations, if they aren't willing to roll out a new browser every three months, how often are they willing to do it? And how are they dealing with browser exploits in between these long cycles?

> OK, fine, but now everything is effectively a minor version increment in Firefox and Chrome, and anyone who doesn't update within 90 days is apparently going to lose all security updates.

So how is this different? If you are not willing to update, you're not getting security updates anyway.

> That is not a viable combination for any users who value a stable platform they can build on more than cutting edge toys.

This is either hyperbolic or delusional. You tell me which. I'm using the latest version of Chrome. I also have Firefox 5 installed. They both work on every site I've visited lately. The only exceptions are some internal corp sites that only work with IE, and those clearly didn't work with FF 3.6 either (also I think those were all recently upgraded or retired so they're no longer an issue, but I'm not certain).

If you want to build stable apps, then use the stable pieces of HTML/CSS/JS/whatever. No one says you have to use the latest feature that Chrome/Firefox/IE/Safari added. You can choose to build on a stable platform without running a 2-year-old browser.


> A lot of people very clearly are willing to update every three months.

...and a lot of people very clearly are not. So now what? We say, "this doesn't work for lots of people", you counter-point that it does work for a lot of people ... both statements are true and nothing has been accomplished.

> And for people using Chrome, they get updates even more frequently.

And for people using Internet Explorer, they get updates much less frequently. Guess which browser still has the lion's share of the market? (Hint: http://getclicky.com/marketshare/global/web-browsers/)

> When the upgrading is painless, no one minds doing it.

Right, and that's the rub! Upgrading is not painless! I think you, and I, and Silhouette are in agreement here: if upgrading were painless, no one would mind doing it. The problems seems to be that for you, "painless" means, "I have to download and install it", and for us, "painless" means, "we have to answer support calls about what happened to the bookmarks menu and why X page is no longer working even though it was two weeks ago and by the way the back button looks different and I don't think I like this new version..."

> If you are not willing to update, you're not getting security updates anyway.

Nobody's objecting to security updates!

This very statement is so indicative of what the problem is here: that security updates are being conflated with application updates. Security updates are fine! Corporate IT will almost always roll out a revision change, no problem!

Microsoft's Update Tuesdays? Usually OK!

Service Packs? Let's wait!

Now Mozilla's got a huge troll face on and is saying, effectively, "Hehehe, here, have an update ... it might be a security update, it might be a service pack! Enjoy!"

> This is either hyperbolic or delusional. You tell me which.

See, now here's where I want to make this personal now.

Don't pull that shit. Just because you don't understand someone else's problem, doesn't mean their problem is insignificant. OK?


> ...and a lot of people very clearly are not. So now what? We say, "this doesn't work for lots of people", you counter-point that it does work for a lot of people ... both statements are true and nothing has been accomplished.

Now nothing. I never said there weren't a lot of people on the other side. I was responding to Silhouette's comment: "I'm not, and I don't think a lot of other people are either." He's not willing, and doesn't think many others are. That's incorrect, because indeed many others are. "I don't think a lot are" is not the same as "I think a lot are not". (Compare: "I don't think a lot of people are fans of Justin Bieber." vs "I think a lot of people are not fans of Justin Bieber." These are very different statements.)

> And for people using Internet Explorer, they get updates much less frequently. Guess which browser still has the lion's share of the market?

And? Are you advocating that Firefox should follow IEs lead? It looks like IE's lead is dropping almost as quickly as Chrome's share is rising.

> Right, and that's the rub! Upgrading is not painless!

It would be a hell of a lot less painful if it didn't involve a massive rollout of new software every 18 months. Chrome's always-updating model has proven to be painless for a lot of people.

> for us, "painless" means, "we have to answer support calls about what happened to the bookmarks menu and why X page is no longer working even though it was two weeks ago and by the way the back button looks different and I don't think I like this new version..."

So use IE and be done with it, or maintain FF 3.6 indefinitely yourself. If you want your browser to remain unchanged for very long periods of time, and Mozilla won't help you with the goal, I don't see what your other options are. I really don't see how Mozilla has an obligation here.

Also, if you upgraded frequently, the changes that arrived wouldn't be quite so large. When you follow the "big bang" software rollout technique, it's a lot of changes dumped on the user at once. If you roll out smaller changes, users have less to adapt to any any given time. Maybe just send an email telling them where the bookmarks moved to.

> Nobody's objecting to security updates!

My point was that you have to go through testing for security updates as well. I concede that you're less likely to have users calling to ask about why the bookmarks moved after a security update, though.

> Now Mozilla's got a huge troll face on and is saying, effectively, "Hehehe, here, have an update ... it might be a security update, it might be a service pack! Enjoy!"

That's hardly fair. What Mozilla is saying is more along the lines of "Here's the latest and greatest." And "It's too much effort to maintain a bunch of old branches indefinitely, so we're not doing that anymore."

> See, now here's where I want to make this personal now.

You want to make it personal because you took offense to something I said to someone else? How thin-skinned are you?

> Don't pull that shit. Just because you don't understand someone else's problem, doesn't mean their problem is insignificant. OK?

I did not say his problems were insignificant, and you need to stop getting your knickers in such a twist. I was responding to a specific statement: "OK, fine, but now everything is effectively a minor version increment in Firefox and Chrome, and anyone who doesn't update within 90 days is apparently going to lose all security updates. That is not a viable combination for any users who value a stable platform they can build on more than cutting edge toys." This is indeed hyperbolic (or possibly delusional). Minor versions with new functionality very clearly is a viable combination, because it's been working for Chrome for some time now.

The idea that you need everyone on FF4 for a year so that you can have a "stable platform" for development is ridiculous. If the move to FF5 is going to break everything, then you're already screwed, and your best bet isn't to dump a year into development for FF4, but to find a way to write apps that won't break every time the browser is upgraded. You cannot stay on FF4 forever (I hope), so at best you can postpone the problem and probably make it much harder to resolve in a year.


If you are using Java applets, then yes, migrate away. That's a technology that's effectively deprecated since at least 5 years. And yes, my point is: move faster.

Regarding stability: yeah sure. Amazon never works, Google.com is always down, ebay doesn't render in half of the browsers. On top of that, all the owners of the millions of websites struggle every day to keep up with all the browsers. Clearly, the web is nonviable and should be shut down.


> If you are using Java applets, then yes, migrate away. That's a technology that's effectively deprecated since at least 5 years.

That's simply not true, though it is very revealing that you think it is.

In fact, every browser has made major developments in Java applet support far more recently than that, Java itself has evolved significantly in that time, and of course there are now several rather advanced programming languages that compile down to Java bytecode and the applet mechanism lets you use those languages in developing web-based tools.

Whether or not you personally know anything about it, Java applets are widely used in several significant industries, often for configuration of networked hardware or UIs for in-house tools. The global investment in this technology is probably rather large, and you are basically asking that everyone who has spent time and money on the technology should throw it away because your pet browser can't manage a point release without breaking it? Well, sorry, but other people's browsers can, and you just look like your quality control is broken with that argument.

> And yes, my point is: move faster.

Why? Quite a few of these tools just work, and need little if any maintenance, because the systems behind them also just work and are still in use. You are arguing that people should completely rewrite systems that are working fine and have no current issues, so your browser can advance into untold new territory without bothering about backward compatibility. Your reality check is about to bounce.

> Regarding stability: yeah sure. Amazon never works, Google.com is always down, ebay doesn't render in half of the browsers.

You do realise that both Amazon and Google have had major outages recently, taking down huge numbers of sites that rely on their service infrastructure, right?

In fact, contrary to all the advocacy about how cloud-based computing is less risky than doing things in-house because the Internet giants have redundant this and scalable that and on-call the other guy, the record so far is pretty poor.

As far as their front-line services, of course the real giants manage to keep something up pretty much all of the time, but even then Amazon has suffered from several obvious bugs in recent months, which must be hitting them in the budget for both the PR and customer support departments.

Google aren't much better. Their main site works fine, but for example one client of mine uses Google Docs and I'm not sure we have ever managed to get a meeting together when one of the team's systems didn't have basic access or drawing bugs while trying to use it. They fix one thing and break another. So do Facebook. Don't even get me started on smaller sites like Reddit falling over every ten minutes (remind me again what their infrastructure is and how often they've attributed total system failure to that outsourced infrastructure).

So yes, I stand by my comments on stability, and I think you have a very rose-tinted view of the reliabilty of big name sites such as those you mentioned. The facts just don't support your argument.


Certainly corporate IT guys sometimes take the flak when stuff breaks, but the really good* corporate IT guys manage to turn major breakage into a justification for a bigger budget.

"...blame the big software and infrastructure providers, who haven't yet collectively invented a robust global IT architecture where risk can reliably be localised to the user at fault."

So many of the problems of building a robust global IT architecture have already been solved in the Internet itself. When Big Enterprise resists using the Internet as it's designed, as a loosely-coupled system, with rules (RFCs, etc.) then it ends up with the sorts of problems in browser testing like the OP is talking about.

"Or step up and do something about it and get very rich..."

That's the best thing in your comment. I would have upvoted you just for that. If my previous thesis has any value, that a big problem with corporate IT is attitude, how do we fix it? Send everyone to reeducation camps in the gulag? I can't think of how to profit from that, though it might be fun to watch :)

*Depending on the interpretation of "good."


I get the feeling you're mocking me. :-) But I'll play along...

> So many of the problems of building a robust global IT architecture have already been solved in the Internet itself.

Ironically, I think the Internet is a fine example of what I mean. Before the Internet, no-one could DDoS a whole business out of existence, because business models weren't vulnerable to that sort of instant mass attack. Before the Internet, you didn't get rapidly evolving viruses that could sneak into your corporate networks because one user clicked the wrong Facebook link during their lunch break and cause you weeks of grief to remove because they could propagate quickly throughout a whole section of your LAN. Before the Internet, one executive doing something dumb didn't result in every confidential report to which that executive had access being uploaded to someone who would extort money from you to keep it quiet. Before the Internet, your database front-ends were in-house, and one error in a front-end didn't leave you vulnerable to having all your customers' credit card details stolen.

Does this mean the Internet is a bad thing? Of course not, it's overwhelmingly positive on balance. But it presents many fine examples of what can happen if the damage causable by a single rogue element isn't effectively contained.

> If my previous thesis has any value, that a big problem with corporate IT is attitude, how do we fix it?

Exactly. You are assuming that the problem here is the attitude of corporate IT groups, and not their choice of tools. I am suggesting that Firefox and Chrome are making themselves into unsuitable tools and the responsible thing for corporate IT to do is to not use them, presumably going back to using a stable IE version and Microsoft's well-developed management tools instead.


I didn't mean to mock you and I really did like your comment about how do we profit from this. That really is the important question for HNers. That and "how do we fix it."


> Corporate IT has to get better and faster, or they will get marginalized by cloud hosted solutions that can move faster and deliver superior experiences at better cost.

Who says the cloud-hosted solution isn't more expensive? Who says "experience" is the goal? A company cares about making money, and an internal browser-based app is simply a way to make money more efficiently.

Often, the "corporate mindset" means cheap. If you don't need to worry about upgrading your browser, you don't need to blow money on developers just to keep up with cutting edge browser design and you can focus on developing technology that actually makes you more money.

For example, if you had a system that involved scanning physical documents into an image repository, then having individual workers review and annotate every single document (using a browser-based app) and then manually make corresponding changes to the customer database. You are paid by an SLA-based contract based on the rate and number of images you are able to process in a billing period.

Where would you rather invest your money? Keeping the crusty annotation browser-app up to date with the latest shiny new browser changes, or implementing OCR to increase the speed and efficiency you can process documents?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: