> We are offering to buy a new computer with a modern browser for any of our customers who are stuck with IE7
Great PR, since practically no-one is going to take them up on the offer. If you're on IE7 you're probably on it because MegaCorp's Intranet Application '02 Enterprise Edition doesn't work on anything else. Meaning the new computer will break their LOB application.
It's also possible it won't cost them any money in the long run, if their definition of "customer" is limited to the people posting jobs [1].
The other option is they are elderly or just don't care. They have that E-Machines Pentium 3 future proof 256MB of RAM Windows98 computer and they'll use it until they die, because shouldn't everything that costs over $1,000 dollars last for 20-30 years?
When I recently asked my grandfather about his browser preference, he said Yahoo. I came to realize that he believes Yahoo IS the web; it's his start page on IE.
Yes, just like your car will last you 20 years. If you drive a car from 1994 you don't expect to be able to drive 90 mph or offroad without running into major issues. Should cities keep their infrastructure backwards compatible for people with old cars?
You likely have been upgrading and maintaining your car. Users with IE7 who expect the world to freeze with their hardware are like car owners who do not change their oil yet would be amiss when their car stops functioning after 10 years.
I don't think anyone running IE 7 honestly believes that. But the promise of the Web was you got to avoid minimum hardware requirements and things worked everywhere. HTML and CSS were supposed to be backwards-compatible by degrading gracefully. This point has been lost. There's really very little point in having an open standard if the only way to run anything is to update your browser every 6 weeks.
It's apples and oranges. In 1994 people went over 80mph all the time, and they still do. If you maintain a car well, it will continue to be able to do that. By contrast, though... a PC perfectly maintained from 1994 until now would be hopeless in today's infrastructure.
> a PC perfectly maintained from 1994 until now would be hopeless in today's infrastructure.
Not if they upgraded both their hardware and software along the way. Even without upgrades, their computer might function just fine, but they should not expect to browse websites created with technologies that were not yet dreamed of when their computer was born.
People expect to make phone calls on their 5 year old phones, but it would be unreasonable for them to complain that they cannot download the latest version of snapchat on it. People with old browsers and hardware can expect old websites and software to work for them. It is unreasonable for developers to be required to create new websites that work for outdated and insecure browsers.
If it's "learn to use a VM or lose your job", coupled with a good computer basics course, I'm pretty sure he/she will be properly motivated.
I work at a megacorp that recently switched the local branch to terminal servers + virtual machines, not one has had any difficulty with the retraining, and the previous megacorp I worked for had a 70 year old using a pretty complex environment.
My grandmother went from being afraid of clicking a button to being a decent internet user, using both IE and Firefox (since her hospital's website didn't work in IE).
There are two reasons why most places don't use this: they've been skimping on RAM or their IT people don't want to learn something new. Neither reflect well on their IT management.
It might be hard to believe, but there are plenty of people in the world whos job has nothing to do with being tech-savvy.
In this specific case the persons job is to manage HR process, not to keep their IT infrastructure up to date. The computer and browser are just tools.
The above comment still holds. If your job is to use the tool all day, every day, one would expect that you would learn how it works.
I see the same issues as well where I work in education. Teachers, whose job is literally all about learning, are terrified to learn about technology tools for their classroom.
I'm not saying they have to be tech-savvy, where did I say that? And keeping the IT-infrastructure up to date? What has that got to do with anything? Did you reply to the wrong comment?
If part of your work depends on using a computer (to manage HR or whatever), you can't be afraid of doing basic tasks like maximizing a window, turning it on, etc.
Just like a carpenter can't be afraid of picking up a hammer.
You would think, but there are plenty of barely competent tradesmen around. Why should it be any different here?
There use to be a phrase referring to wood workers [edit, my mistake - boat caulkers], 'His mallet rings.' Meant as a complement. When you've got the skill to do it, the beats of your mallet create a particular pattern of sound. It's a different mindset to just picking up a hammer ... or a nail gun as the case may be ... and smashing something in. It's, pride in your effectiveness, a dedication to get better at a task.
It's pretty rare to find someone these days whose hammer rings.
IE8 has compatibility mode that will work just fine will all those "designed for IE6" pages. Same for IE9. In IE10 and 11 I found the compatibility mode to be less accurate in mimicking oldIE.
I wonder if there'll be a rush for IE10 compliancy when Windows XP support comes to an end like COBOL systems needed Y2K compliancy leading up to 2000?
I assumed the whole point of the offer was that they'd be able to run both computers. The old works-with-our-"enterprise"-software computer is kept alongside the new web-browsing computer.
Thats not really how enterprise computing policies work :) If its not centrally administrated, its probably not allowed. At least in the type of environment where people are still on IE7.
I think you missed a hyphen. I was referring to the horrible limited software that many companies use that always seems to have "enterprise" in the name.
If you're stuck in the sort of toxic environment where a new free machine is not allowed because "policy" then nothing can help you.
> IE7 users make up 1.22% of our traffic right now, and this will decline as more computers are upgraded and can use modern browsers.
No computer exists that is able to run IE7 but not IE8. And because IE7 came out way past the "optimized for IE" age, I doubt there is software around that requires 7 and doesn't work with 8.
This is in contrast to 6 which is what IE was stuck in for years, so software began depending on that.
If you could upgrade from 6 to 7, then you can upgrade from 7 to 8. Even more so considering that IE8 has an IE7 compatibility mode built in that can be enabled without having to touch the site itself (by setting the HTTP header in the server).
The same is true for local software embedding the IE control, but there you need to set some registry flag to do it.
There is no excuse for sticking with 7 and 8 is so much better to develop for. It's 2014. I would stop caring about 7. People still using 7 are used to sites not quite looking right anyways (as the majority of sites stopped caring) and in all likelyhood, they might not even notice the odd rendering glitch.
Actually no, you are completely wrong. It might be a popular opinion but it's wrong.
Some facts:
1. Firstly, there are a couple of COM APIs that were broken with IE8 which mean that some horrible "intranet applications" that use ActiveX won't work with IE8 properly. They worked fine with IE6 and IE7. These are now no longer supported by the vendors with no upgrade path so people are stuck with IE7 whilst applications are rewritten or disposed of. This can take years. In fact I know a company that has taken 4 years to rewrite an ERP system away from this model. The compatibility flag deals with some rendering issues but it doesn't change the script engine or the ActiveX hosting situation.
2. No they can't install another browser side by side and just keep that for legacy. Chrome has a poor privacy and configuration support. The GPO side of it really is crappy. Firefox ESR is impossible to configure using GPO. Not only that users don't want to browser-juggle. Most of them don't actually give a shit about any of this as long as it works.
3. Also, IE7 was released in 2006. I personally maintain software that was written in 1988. People are very quick to hang software, particularly the non-engineering background trendy startup pushing culture. IE7 isn't going away until April 11, 2017.
To be fair, I'm recommending people away from the web and the cloud for business critical applications these days. The churn, culture and attitude (as your post outlines so readily) is very negative and a realistic 10 year cycle isn't possible any more. People need stuff to work undisturbed for years for their investment to be recouped.
I fail to see how Microsoft's decision to not fix these proprietary APIs in future IE releases is somehow the fault of "the non-engineering background trendy startup pushing culture".
Your company bought into a single-vendor solution that was then (as is TYPICAL of said vendor) dropped like a rock. Tough.
The two points are separate. The former is a fact, the latter is a general attitude.
Not our company fortunately, but I have stuff to integrate with their systems. They had supply and maintenance contracts and soure escrow. The supplier went under rather than dropped the product - this is not typical. The replacement is being built by ex-members of the supplier working for the company.
They won in a bad market so it's hardly a "tough" situation.
>These are now no longer supported by the vendors with no upgrade path so people are stuck with IE7 whilst applications are rewritten or disposed of...I know a company that has taken 4 years to rewrite an ERP system away from this model. The compatibility flag deals with some rendering issues but it doesn't change the script engine or the ActiveX hosting situation.
The company should light a fire under the ass of their vendor or development department if they're being forced to live with some very serious security risks.
>I personally maintain software that was written in 1988.
Why are you supporting software that is a quarter of a century old? If it has undergone significant rewrites to work on those new-fangled color monitors, then you understand why things need to be upgraded.
>People are very quick to hang software, particularly the non-engineering background trendy startup pushing culture. IE7 isn't going away until April 11, 2017.
What is "non-engineering background trendy startup pushing culture" supposed to mean? While HN has a charlatan element, you can't legitimately think that the startup culture here isn't dominated by engineers.
>I'm recommending people away from the web and the cloud for business critical applications these days.
Do you also scream "la la la" while the tips of your fingers are lodged in your ears whenever in architecture meetings? A web browser is an ideal consumer (ubiquitous, cross-platform, cheap) of a large number of business applications and high availability demands writing software that's internet-aware (that feels so strange to even have to type).
>The churn, culture and attitude (as your post outlines so readily) is very negative and a realistic 10 year cycle isn't possible any more.
It sounds like your perception of the industry is antiquated. A 10 year cycle without maintenance to keep the codebase secure/running on modern hardware/platforms?
The company should light a fire under the ass of their vendor or development department if they're being forced to live with some very serious security risks.
The vendor doesn't exist any more. This is a realistic problem. They had source escrow which results in them hiring a development team to port it. This has taken 4 years, including retraining all 5000 users and porting data. This isn't some shitty TODO list app or an Intranet - it's a full ERP with over 2 million lines of code and 500Gb of raw non-binary data. And yes this is still cheaper to run than SAP/Oracle.
Why are you supporting software that is a quarter of a century old? If it has undergone significant rewrites to work on those new-fangled color monitors, then you understand why things need to be upgraded.
Because the 30 year paid for and guaranteed support lifecycle isn't over yet. Not only that, it's tied to the specific hardware platform which is an embedded 80286. It doesn't have a monitor attached - it has a 40x8 text LCD screen and an RS232 port. New requirements and bugs do appear.
What is "non-engineering background trendy startup pushing culture" supposed to mean? While HN has a charlatan element, you can't legitimately think that the startup culture here isn't dominated by engineers.
I use the phrase engineer loosely with respect to software as it has in the last decade or so come to mean a different thing. It's gone from individual who carefully plans and creates something with meticulous attention to detail and extensive knowledge of requirements to individual who makes something with little thought. Note: this isn't every case but it changes the meaning of the word, much as you can say "I love you" too much...
Do you also scream "la la la" while the tips of your fingers are lodged in your ears whenever in architecture meetings? A web browser is an ideal consumer (ubiquitous, cross-platform, cheap) of a large number of business applications and high availability demands writing software that's internet-aware (that feels so strange to even have to type).
Yes, it's actually my job to ensure that due diligence is done and put good engineering standards and technology in place. La la la doesn't cut it but I have to think ahead 20 years in some cases and make a call. If something doesn't make sense in that timescale, then it gets discarded. Your personal opinion isn't necessarily that of a risk assessment.
It sounds like your perception of the industry is antiquated. A 10 year cycle without maintenance to keep the codebase secure/running on modern hardware/platforms?
Industry? There are two industries at the moment. The one in the technology press and everywhere else. I firmly circulate in the latter. There is not a noisy presence but a large and realistic one that makes critical cogs turn behind the scenes. Whether or not this is "antiquated" or not is purely conjecture.
This. This. This. Thank you for explaining the reality of the situation.
I've worked with lots of different companies over the last 20 years with lots of legacy intranet systems that are too large, complex, and customized to make upgrading them anything less than a multi-million dollar multi-year endeavor, and yet there's always someone who says, "Just rewrite the thing in [favorite framework]!"
I've seen some programmers actually try to do the rewrites themselves. They code for a week or two, discover just how much business logic has been written into the thing over the last 20 years, and abandon it to start looking for employment elsewhere.
I can't tell which point you're arguing. Sounds like you're losing good employees.
The 'reality of the situation' is that you're no longer retaining any young talent in your company, because you're stuck writing COBOL. The Frankenstein-of-an intranet program you've stitched together is now too big and too complex to work with; only the guys who built it in the first place have the guts to stick their fingers in the code.
Sometime around 5 to 10 years ago, you stopped building software and started slapping a bunch of dirty hacks together to get things to 'just work'. The technical debt is insurmountable, and it's only getting worse. The software is 20 years old. What will happen in the next 10 years? Maybe then the company will be able to afford a rewrite...
Except now the technical debt has crept in to the workflow of your users. People are doing things that computers should be doing. Every process involves some hacky workaround to get your ancient system to play nice. You're printing on dot-matrix printers and scanning it back in. Other companies don't know how to hand you data. CSV files over FTP transfer? Maybe we can just email you the files every week so your mail server can gobble it up and hand it to your ancient application? Other companies are scaling. Your bottom line is hurting.
Now we're 30 years in, and the guys who built it in the first place are looking to retire. There's nobody you can 'pass the torch' because none of the new employees over the last decade have lasted more than two years; they all went on to play with silly 'kid' languages like 'Ruby' and that funny 'Cloud' fad. You'll have to find someone with talent, years of experience in your antique system, and yet isn't thinking about retirement within the next decade. Time to post a job opening for a COBOL ninja-rockstar!
>Thank you for explaining the reality of the situation.
Where reality means a serious failure in tech leadership.
>I've seen some programmers actually try to do the rewrites themselves. They code for a week or two, discover just how much business logic has been written into the thing over the last 20 years, and abandon it to start looking for employment elsewhere.
Having been one of these people that "try to do the rewrites" himself, I left because paying off technical debt wasn't prioritized. It's not just about having a modern stack, it's about being able to hire maintenance programmers and not being forced into trying to keep a sinking ship afloat.
> Thank you for explaining the reality of the situation.
I love it when people use this phrase. The "reality of the situation". Yes, this is how things are, and they will continue to be that way until we change them.
There is a world of difference between "refuse to support IE7" and "let's rewrite everything in [favorite framework]." Our startup is squarely in the enterprise space, and we don't support IE7. Our app will literally display a "you shall not pass" modal if you try to log in with IE7. Our client list includes a lot of local governments (cities large and small, counties, GPOs, etc), and we still manage to get by just fine without supporting IE7.
I think you'd be amazed at how small of a market you're giving up by telling everyone you simply cannot support IE7. When you just accept "reality", you never bother to push the issue, and you never make progress.
Since when was it a good idea to develop a system that locked users into an antiquated browser, and then insist decades later that all people using that application also use the same antiquated browser for everything else they do?
The people who demanded software with a user interface that would run for 30 years without modification were wildly unrealistic fools, and the people who told them they could do it and took their money for it were unethical scammers.
>The vendor doesn't exist any more. This is a realistic problem.
Yes, it's a realistic problem of "if your vendor goes extinct, you should start moving." If you're in charge and you let your business get stuck in this spot, the liquid lunches need to stop.
>This has taken 4 years, including retraining all 5000 users and porting data. This isn't some shitty TODO list app or an Intranet - it's a full ERP with over 2 million lines of code and 500Gb of raw non-binary data.
5000 users and 500Gb isn't that large. Lines of code is a god-awful measure of work, especially in a verbose language like Java or C#.
I feel as if you have a flippant stance towards web-applications, which I promise you is incredibly misguided. Not everyone here is making TODO apps with Ruby.
>Because the 30 year paid for and guaranteed support lifecycle isn't over yet. Not only that, it's tied to the specific hardware platform which is an embedded 80286.
Where to begin on this? To keep it somewhat related to the parent thread, I'd suggest that code for embedded systems is a different world than sharecropping on a Microsoft technology (or a code-bloat ERP almost certainly containing layers of awful sedimentary hacks placed by numerous outsourcing companies). In 2007, you had your head in the sand (while drinking the koolaid) if you thought ActiveX was a long-game.
>I use the phrase engineer loosely with respect to software as it has in the last decade or so come to mean a different thing. It's gone from individual who carefully plans and creates something with meticulous attention to detail and extensive knowledge of requirements to individual who makes something with little thought.
Oh come on, this is just ageist. Was the guy that wrote something that only works on IE6/7/8 thinking ahead? What about an engineer that created a scenario in which hardware can't be updated? Unless your code is going on a satellite, congrats on over-engineering a solution that only works in a given architecture.
With most consumers thinking of computers as tools that access the web, thinking that you don't have to be incredibly reactive to change is myopic. Do you think that writing maintainable stacks for a changing consumer preferences and patterns is something done without planning?
(before you scoff at anyone that writes code for the web, keep in mind that you previously stated 'IE7 isn't going away until April 11, 2017' as a defense for not 'hanging software')
>Yes, it's actually my job to ensure that due diligence is done and put good engineering standards and technology in place.
This is a different world if you're writing something for an embedded chip that will be made for 20 years. If your customer thinks that she can predict needs for the business 10 years in advance, she's about to have her lunch eaten by another company. The world doesn't work in a "we sell bikes like _this_" way anymore. Give me 6 months and I can write you a SCM and a CLM that will work for the next 10 years _as long as you run it on this architecture with this software installed_, but that's not as useful as "give me 3 months and you're be good for 5 years, we'll evaluate what need in 4 years" approach.
>Industry? There are two industries at the moment. The one in the technology press and everywhere else.
The "technology press" is media and investors.
>I firmly circulate in the latter. There is not a noisy presence but a large and realistic one that makes critical cogs turn behind the scenes. Whether or not this is "antiquated" or not is purely conjecture.
You circulate in the "everywhere else?"
The 'critical cogs' are maintained by kernel, hardware, and protocol devs that are typically paid by a company that doesn't obsess over running ancient code on dinosaur hardware because that doesn't scale with changing demand.
With respect, I feel like you're drawing a line in the sand and being smug because you imagine your problem domain to be on somehow more "pure" side of engineering.
And frankly it does really depend on the company on which point is more valid.
At the end of the day, csmithuk viewpoint is a solution/enterprise architect's view point which caters more to the overall business needs of a company.
And based on my experience, the challenge of getting any new technology in a company that is mature and successful is really hard. The challenge of changing the status quo once that tech has become embedded in their business processes is twice has hard. There is always a benefit/cost ratio. The cost is not just development - it's training, its documentation, its lost time, etc.
>At the end of the day, csmithuk viewpoint is a solution/enterprise architect's view point which caters more to the overall business needs of a company.
Not really. I've worked as an Enterprise Architect and worked in good as well as bad architectures. If you engineer a system that backs the company into a corner of "we can never upgrade," then you're a crappy architect. Even more so if you can't hire someone to step in and maintain a project or have a drought of hardware suppliers.
>The challenge of changing the status quo once that tech has become embedded in their business processes is twice has hard.
Business process is not synonymous with "tech stack." If it becomes synonymous, you done fucked up.
>And based on my experience, the challenge of getting any new technology in a company that is mature and successful is really hard.
That's because some people do tech-for-tech's-sake. If you open the conversation with "hey, if we switch out IIS for nginx/apache, it will take 8 months, but we'll save money on maintenance and licenses, as well as spending less money on hardware," then you're in better shape than just pitching the new hotness. Of course, it's been my experience that these decisions are usually done on a whim in mature companies (hooray business!).
>There is always a benefit/cost ratio. The cost is not just development - it's training, its documentation, its lost time, etc.
Yes, of course. It's also cost of life management, staffing costs for niche/antiquated skills/getting developers willing to do long-term damage to their skills (imagine becoming an expert in coding for IE9 and lower, how do you think your resume will look in a few years?) for short-term profit.
Unfortunately most products built in the early 1990s-mid 2000s suffer from poor architecture. The growth of companies and the technology shift were impossible to anticipate. This is the unfortunate reality of all of those <IE7 dependencies you see. Also there was no foundational research done into how to build these things -- people were pissing in the dark with immature tech and knowledge. This is no longer true fortunately.
Unfortunately for the average corporate, the cost/benefit ratio only becomes an issue when the vendor pulls the rug out from underneath you. In this case when IE7 is EOL in 2017.
We're destined to follow the trailing edge because that is exactly where the best cost/benefit ratio lives. Do nothing is cheapest.
If you engineer a system that backs the company into a corner of "we can never upgrade," then you're a crappy architect.
Sometimes the we can never upgrade is part of the job description. A lot of control software for industrial systems is like that. You do not expect to be thinking about having to upgrade the core code for at least a few decades, as downtime for development and testing is obscenely expensive.
My usage of the word tech is with regards to systems in place that support business processes, so that includes the Excel Spreadsheet all the way up to the ERP system.
I'm sorry, it's hard to go to a company that has already invested in the Microsoft stack, have developers that work in that stack, have many internal and third party applications, have SharePoint all over the place, that run on ASP.NET (and hence IIS), already have sunk costs with SQL Server and Windows servers and make a strong case for changing over. The case might be easy for SQL Server (use PostgresSQL instead) but generally its a no go. I know you used this as an example, but like I said, a lot of it depends on the company.
5000 users and 500Gb isn't that large. Lines of code is a god-awful measure of work, especially in a verbose language like Java or C#.
It's not particularly large but add complexity to that and the work is insane. The application was implemented in C++ and COM for reference which is terse and complex.
I feel as if you have a flippant stance towards web-applications, which I promise you is incredibly misguided. Not everyone here is making TODO apps with Ruby.
Not particuarly. I've spent 18 years writing web applications (big ones) and do today. I'm a pragmatist and web applications are not for all use cases. In fact bar information presentation they are a complicated frustrating area. The emphasis is on smaller applications within this community by comparison which is where my point lies. The reality of real businesses with complicated procedures, processes and regulatory compliance is not something people have to deal with. Fanfaring about the death of IE7 shoots a big chunk of the industry in the face. These people do a disservice to us all.
Where to begin on this? To keep it somewhat related to the parent thread, I'd suggest that code for embedded systems is a different world than sharecropping on a Microsoft technology (or a code-bloat ERP almost certainly containing layers of awful sedimentary hacks placed by numerous outsourcing companies). In 2007, you had your head in the sand (while drinking the koolaid) if you thought ActiveX was a long-game.
The reliability and lifespan expectations are surprisingly similar. The delivered product is different but the processes and procedures are similar. yes in 2007 ActiveX had the writing on the wall but in 2007 the product was already 18 years old and was a 1998 port to COM/C++ from an AS400 platform.
Oh come on, this is just ageist. Was the guy that wrote something that only works on IE6/7/8 thinking ahead? What about an engineer that created a scenario in which hardware can't be updated? Unless your code is going on a satellite, congrats on over-engineering a solution that only works in a given architecture
Not ageist. When this was written, they had Internet Explorer 4 and Netscape 4. Try engineering a solution that fulfills the requirements with any other technology than ActiveX at the time. Even Java wasn't mature enough then. As for hardware it was designed to work for 30 years and they bought enough spare parts to make sure it does.
With most consumers thinking of computers as tools that access the web, thinking that you don't have to be incredibly reactive to change is myopic. Do you think that writing maintainable stacks for a changing consumer preferences and patterns is something done without planning?
This is a temporal argument. When the application stack was designed 16 years ago, the world was a different place. And thanks to the lifecycle guarantees of Microsoft, that guarantee was made up to 2017. In 16 years the same will be true. Time needs to be frozen for certain things and guarantees need to be made otherwise it limits the ability to write off risk against big projects.
If your customer thinks that she can predict needs for the business 10 years in advance, she's about to have her lunch eaten by another company.
Simply no. For some markets, yes but for a lot of traditional supply chains this isn't the case. The company has been around for over 100 years so they've obviously done ok with high lead times and a static model for the last 60 years. Whilst there are some disruptive changes, particularly in the consumer-facing and retail sectors, the sheer amount of work, knowledge and momentum required to enter some industries is prohibitive so they are unlikely to be disrupted by new technology startups.
The "technology press" is media and investors.
Yes. Noise. They focus on the technology company, not the company that uses technology purely as a function of its business.
The 'critical cogs' are maintained by kernel, hardware, and protocol devs that are typically paid by a company that doesn't obsess over running ancient code on dinosaur hardware because that doesn't scale with changing demand.
Actually no. The critical cogs are the ones that generate revenue. The kernel, hardware and protocol work is bought in. The unique algorithm, advantage or working model for your company is the revenue stream, not the stack. The stack is incidental to it. The port from COM to Java SE/EE here is seen as an incidental cost of doing business.
With respect, I feel like you're drawing a line in the sand and being smug because you imagine your problem domain to be on somehow more "pure" side of engineering.
No it's not pure; it's just a considerably larger problem domain than most people anticipate and an unrepresented area of the industry amongst these circles.
Everyone has a story to tell; this is purely mine. I'm not suggest it's right or wrong but there are two sides to every coin and people should consider both before they start a browser witch-hunt.
I can respect your advice in this context with regards to the cloud, but I'm not so sure about web technology in general, if by web you mean HTML5/JS/CSS3.
If you download Firefox 26 today along with your favourite OS and store it on a USB stick, you can restore it in 10 years an run the exact same web applications. That's not really technologically different from storing .NET Framework 4.0 or Java8 on USB stick, to ensure that you can run your that-other-compiled-LOB-program in 10 years. You may need an isolated virtual machine running, but you may need that for the other software as well. Anyone tried running a 16-bit VB6 app lately?
Yes by web I mean HTML5, JS and CSS3, REST and HTTP/SPDY.
Yes I can snapshot everything if I want but the problem with the web is that it is a general purpose tool. It should be a single portal into everything both local and remote sites and applications.
Unfortunately, the rate of change is incredibly large for Internet-facing applications. Intranet-facing applications are left behind. As browsers evolve, which they do rapidly, unpredictably and without compromise[1] a disparity grows until you need two browsers. This is not a situation an enterprise wants to or can afford to maintain, simply because it's below the watermark of concern for 99% of users. This is my point.
The difference between the CLR/JVM and a web browser is that they have a predictable shelf-life and can be maintained separately as they are separate portals into each world. To be fair (I exclude the CLR from this as it's too integrated into the OS), I can ship a JVM with a Java app and it'll run quite happily for another 15-20 years.
And yes I have tried running a 16-bit VB4 (!!) app lately - one of our clients uses one. On 32-bit Windows 8.1, it still works absolutely perfectly (Windows Vista 64-bit+ has no 16-bit subsystem).
I agree. We live in an unfortunate age of extreme technological instability. I think this is typified by the rolling updates we're seeing in many browsers, package-managed applications and operating systems.
I do enjoy the new functionality continuous upgrades bring, but in general they usually result in breaking changes or disagreeable UX changes that users must endure in order to remain compatible with the ever-moving target of modern distributed/web applications.
Some days I feel that I really am alone in the desire to see technology slow down, stabilise, become more predictable and be long-term (10+ year) dependable.
The HN echo chamber of fast-moving cloud/social apps and flavour of the month programming languages feels like it can, in some ways, be harmful to our industry and its reputation. I don't mean this in a derogatory way, but it's easy to forget that 95% of the software out there needs the stability and long-term predictability that "modern", SaaS services just can't offer.
I want my software to remain usable for more than three {browser version increments, Android versions, day job successors;}.
"Unfortunately, the rate of change is incredibly large for Internet-facing applications. Intranet-facing applications are left behind. As browsers evolve, which they do rapidly, unpredictably and without compromise[1] a disparity grows until you need two browsers."
This could be an argument for buying in cloud services (which you expect to be updated and maintained as technology evolves) rather than building solutions internally. Not always an option but where it is this seems like a good argument to buy rather than build, and if possible buy from a company which seems keen to move with the times and allow you to upgrade your browser in future without fear of breaking something
Yes and no. So far cloud services have proven themselves too risky for a lot of people as they suffer from availability problems (Azure), data retention problems (Atlassian data loss), security problems (NSA anyone?), churn and inconsistency (Google apps), data protection and regional law (Amazon S3). I could go on all day.
My larger issue is that the UI gets tweaked constantly. To the point where the app you originally purchased and the one you're currently using may not longer resemble each other and there's nothing you can do about it when it's hosted.
This is a big problem - you are right. Users don't like things changing either. It ranges from a few minutes to adapt to throwing toys out of the pram and having to be retrained on something minor. This is an unfortunately reality.
You've come to exactly the wrong conclusion. web sites from 1992 still work on browsers today. it's IE proprietary activex stuff that's broken and changing rapidly.
Actually no they don't unless they are a really small subset of HTML/CSS.
The box model was broken for years, don't even get me started on tables, JavaScript is the most loosely defined language to have ever existed, there have been several different document parser models (HTML, XHTML, HTML5) it's unreal. At best, most browsers these days estimate what they are doing, diving into some wierd mode full of edge cases purely by accident if you step on the wrong stone.
As for proprietary extensions, they are the most stable in IE. The IE8 change was the first since IE4 and it was primarily a security model change. Now we have NaCl on the horizon (ActiveX v2) and every vendor fighting their own extensions into the "standard" by buddying up for a new "standards" group.
It's a minefield which throwing critical applications into is a bad move both from a logical and risk perspective.
I'm not saying it lacks utility, but it's a risky proposition for a product that needs a defined lifecycle.
The problem has been that IE contained alot of proprietary extensions, which were never a part of the standard. Since IE had most of the marketshare, people used IE, and thus things break when other browsers don't support the same extensions.
Sites following standards should still work. While we have different parsers, they should all be supported today.
NaCl is not a standard, and only works in Chrome, which I can't see changing. ActiveX is a proprietary IE extension, and will never work outside IE. Same with VB script, same with Dart etc.
I had to port an application to IE7 last week, and it works fine in all browsers that has come out since. And this is a EmberJS app using ajax heavily. The web is a great place, as long as you stick to the standards and nothing but the standards. Luckily, the standards are evolving, meaning you can do more and more within the standards, without tying yourself to browser-specific extensions which was the problem in the early IE days.
This is very confused thinking. I'm not sure where to start here.
Browsers are really the most stable backwards compatible platform you'll find provided you:
1. stay away from proprietary extensions, applets, plugins, and what have you.
2. stay away from the new features that aren't standardised yet.
The different parser models are there, and are STILL there. they will be there forever. Why? because DON'T BREAK THE WEB.
"At best, most browsers these days estimate what they are doing, diving into some wierd mode full of edge cases purely by accident if you step on the wrong stone."
Evidence or it didn't happen.
"As for proprietary extensions, they are the most stable in IE. The IE8 change was the first since IE4 and it was primarily a security model change. "
IE's proprietary extensions are the most stable, except they aren't, at all? Are you reading what you're writing before you send it?
By popular demand IE has been forced to expunge the worst of it, and support standards. The ones that don't change every browser release.
"Now we have NaCl on the horizon (ActiveX v2) and every vendor fighting their own extensions into the "standard" by buddying up for a new "standards" group."
Well then don't use those.
"It's a minefield which throwing critical applications into is a bad move both from a logical and risk perspective."
It's only a minefield if you go into it with extremely misguided and confused thinking like you apparently have. There is a huge, rich, extremely stable platform here that you missed out on because you ironically are only interested in the whiz bang new shiny feeding frenzy going on. Just don't use those parts that are changing rapidly. they are easy to spot. Use the old parts that haven't changed since 2004. If they've been around for 10 years they'll be here for 10 more years.
Your argument applies to anything that has been obsoleted. What about the poor bastards who can't afford a car and depend on a horse and buggy? The highways are too dangerous for them. What about those "long-term" planners who standardizes their IT infrastructure on Jazz drives? And the poor sods who think all new laptops are awful because of that one printer they bought in 1987 that needs a serial port?
IE7 and COM are fucking ancient. And they're both shitty technologies. COM, especially, is a sad, disgusting 1990's remnant of "guru"-level C++ shit-baggery that is the only technology I'm aware of where the boiler-plate code is 2x to 3x more than the actual code. I'm glad those are put on the back-burner by MS.
Unix is from 70's and it's fucking solid. You wrote C code in 1975, you could probably port it to Ubuntu Linux without too much effort. You "standardized" on "enterprise" (a hilarious word, btw) technologies like IE7 + ActiveX? You deserve all the pain that is being dished out to you.
The crying and stomping of feet that happened at my company after IT deprecated WinXP + IE6 was music to my ears.
The world doesn't need IE6. It doesn't need IE7. It doesn't need COM. What it needs is fewer "enterprise architect" types who read too much MSDN Magazine and develop brittle "solutions" based on ActiveX and sell them to unsuspecting victims.
I am pretty sure that these IE7 users (users of NursingJobs.us) are probably browsing from a hospital, where I know for a fact IT policies can be just as bad, if not worse, than at large corporations. I don't think the users have a choice here (besides using a different computer at the hospital or surfing from home).
IE7 shipped with Vista. I've seen a few organisations that started deploying Vista and updated their XP systems to IE7 so all their workstations are running the same IE version.
Admittedly, there aren't many of these companies given most gave Vista a miss in favour of 7 or something else entirely, but they do exist, and it is a plausible reason that IE7 is still around for some.
Note that the compat mode may mean that you are miscounting IE8 users in IE7 compat mode as IE7 if you are doing a naive user-agent detection (I only mention it because I did and started blocking IE8 users!)
Both will emit "MSIE 7.0" in the user-agent, but IE8 will have Trident/4 while IE7 lacks any such token. MSIE 11 does away with "MSIE" in the user-agent altogether.
There's a X-UA-Compatible header (and meta variable) you can emit to ask for no compat checks.
Related: Kogan (an electronics vendor here in AU) has an IE7 tax on all of their products to pay for the upkeep required to develop supporting IE7. This follows the succesful implementation of an IE6 tax some years ago.
It's an interesting idea, I suppose, if a bit smug; I've always found it sufficient just to pop up a note saying something along the lines of "Look, I'm sure you have a good reason for using IE 7, and I'm not going to tell you that you shouldn't. But it's no longer reasonably possible to test in that version of the browser, and I therefore can't warrant everything on this site will work properly in it; I don't particularly expect problems, but you should know they might happen, and if they do, there's not a lot of help I can offer beyond suggesting you instead use a newer version of IE, or an alternate browser like Firefox, Safari, or Chrome, all of which I have tested and can warrant." We're all adults here, after all, even when "we" is mostly composed of triathletes, who are wonderful, athletic people and often not completely barking mad, and I've found this approach to produce quite good results and only a modicum of whining.
As for Kogan, their site seems anxious that I should know someone bought an SD card a minute ago in some antipodean town I've never heard of. I can't think why.
Oh, and someone else just bought a camera battery. It's interesting to see this sort of thing pop up, to be sure, but why would anyone bother? Does it help conversion rate? Mainly it just seems like an annoying distraction from the blog post I'm trying to read.
I've no idea; I've never actually purchased any Kogan product. It nevertheless made news when they released the tax and they repeated the process so I guess it worked out for them?
(The lesson here is that many people will probably just blindly pay whatever the final cost is without checking the itemised receipt and why it costs what it does)
Yeah, we've got a client who still uses IE for Mac, and refuses to consider using Safari, or anything else, as his feeling is that the internet should conform to him and his browser, not the other way around.
I had a report from the manager in another company who bought our hosted solution that everything was misaligend.
Turned out clicking a link from an email opened Netscape Navigator 4 for him!
Normally he uses Internet Explorer if he clicks on Internet on his desktop
We also make software for healthcare customers, and asked the same question re: IE7 support internally. Sadly our stats show that IE7 usage for our clients is at 59%! Down from a peak at 81% but still crazily high. We're hoping the April no support for XP deadline will change things but sadly IE7 is far from dead in UK healthcare.
I'm surprised no one has yet created a database where people can anonymously submit ranges of IPs where a lot of users are on IE7 and other older browsers. This would paint a big ol' bullseye on those organizations since it highlights them as easy targets for exploits that target older browsers.
The newer browsers actually come with a lot of feature-induced security problems too. Microsoft continues to release security updates for IE7 so it might be better to use than a newer version of IE that could have HTML5 exploits.
You can take it from the other end. These employees are locked on IE7/8 because there's not enough external forces to make it a business issue. When they won't be able to use critical resources because of their browser or OS, the upgrade will just happen, how painful and costly it will be (as long as it's less costly than not accessing the said resources)
Actually I agree with this line of thinking. I we could in fact fork IE7, replace it at the system level and people were enthusiastic enough to patch bugs and security holes forever, why not.
From what I understand, there's a reasonably large market for temporary nurses, for times when a hospital is understaffed. I suspect it's acceptable to look for a new gig before your current one ends.
Edit: It also looks like hospitals, not nurses, are the actual customers.
Their clients are, as far as I can tell, the hospitals posting the jobs. Other users are mostly accessing the site on home computers, where they can almost certainly install some other browser which isn't as broken.
While in general a hospital may not have computers for this, their hiring manager is likely to be able to take an extra machine onto the network.
> My ultimate goal though is for it to be presentable in IE7 with a top notch experience in anything newer, makes it a little easier.
I think that's the exact right attitude.
I work in an environment that supports back to IE7 and I really get a kick out of creating robust solutions that work in crappy or older browsers.
Admittedly I work with web sites, or simple applications, rather than full on web applications, but I find starting with sensible HTML/CSS/JS and using progressive enhancement usually gets me 95% of the way there.
"Wayne Gretzky once said “skate where the puck is going, not where it’s been”"
No, no he did not. Steve Jobs said that Wayne Gretzky said "skate where the puck is going, not where it's been". However, I'm sure one day Wayne Gretzky will quote Steve Jobs saying that he once said that you must skate to where the puck is going, not where it's been. That day will be quite awesome.
On that note, what happens when the puck goes past its original position, as inevitably happens in a game of hockey? What does Wayne Gretzky do then? Ignore it?
'[Wayne Gretzky's father] Walter taught Wayne, Keith, Brent, Glen and their friends hockey on a rink he made in the back yard of the family home, nicknamed the "Wally Coliseum". Drills included skating around Javex bleach bottles and tin cans, and flipping pucks over scattered hockey sticks to be able to pick up the puck again in full flight. Additionally, Walter gave the advice to "skate where the puck's going, not where it's been"'[0]
> Doesn't MSIE8 have a MSIE7 compatability mode that basically runs the IE7 rendering engine in a wrapper
Of course not, that was obviously the right way to implement this so they had to do something worse first. IE7 compatibility mode works plausibly well for visual display but as eonwe's link pointed out there are still some key differences.
That link, however, doesn't really mention the worst part: IE8-as-IE7 does not have a compatible DOM or JavaScript engine. They're using the IE8 JS engine under the hood which is generally better but, among other things, it started raising exceptions for previously ignored bad code. I found out about this shortly after IE8 was released when my then-employer's Oracle apps stopped working because they used a really old version of a UI toolkit which at one point set zIndex to null before assigning it a new value. This is clearly invalid according to the specs but prior to IE8 it appears that nothing threw an exception. I ended up patching the JS file because getting a patch would have taken aeons and Oracle support actually called me asking if they could redistribute my work to other customers!
The good news is that Microsoft finally came up with the right way way to do this in MED-V, which will seem very familiar to anyone who's used e.g. VMware Fusion: you run antique versions of IE seamlessly inside a VM and the host's Internet Explorer can be configured to load certain sites inside the guest so you only take the performance / feature / security hit for your legacy enterprise apps instead of the entire web:
Yes, given that I'd already released the code on a couple of customer lists but it was tempting to ask for a license fee, particularly given the arrogant first-line support we'd had to slog through to report the bug. “We don't do Microsoft's beta-testing for them. We'll start testing after IE8's released” – a week after the release
Wow... that really assumes a lot on their part to have that attitude. Like... MS will give a rat's ass about how some crappy Oracle app will work in their latest browsers. Or that anyone will take Oracle's response of "report this bug to MS" six months later as useful. But... this is probably the same attitude other big vendors have about Oracle's stuff too.
Shouldn't at some point the cost of all websites in the world being broken on your corporate machines be a bigger problem than having to do some work on some antiquated LOB app you've considered rewriting anyway the last 5 years?
Do these weirdo F500 still demand railroads to operate steam-trains for them, since that was the last thing they read about last time they received a telegram?
In what world do these people live where perpetually staying in the past is not a problem?
Having worked in a large bank, I can maybe shed some light on it. It's all about balancing benefits, risk, cost and opportunity cost. Large corporates typically have budgets for projects/investments and for Business as Usual (BAU). BAU budgets aren't a good place for a big infrastructure change because of all the dependencies that may or may not exist - you simply don't know until you do the project to get it done.
As budgets are scarce and ideas for projects are typically plentiful, someone somewhere has got to come up with a business case for each project and unless the cost benefits of doing it are significantly great then it ain't going to get done - there are going to be better investments for that org. It ain't the techies who are in charge in corporates, they need to do the stuff that the business wants done.
The other lens of corporate IT is that they are typically risk averse and want changes to be controlled. IT folks do not change if they can help it - because sometime upgrading something broke something else or maybe they'd rather to do something more interesting.
And your company has an IT department that thinks IE7 is more secure somehow, or you have some proprietary enterprise software that takes advantage of the quirks of IE7 and breaks without them.
I've often received bug report screenshots or sat in watching a customer screenshare using our product in IE6 on literally a 800 x 600 screen. Each time it makes me cry inside and I debate just ordering them a new computer. That said, as others have pointed out here, almost nobody these days running IE 6/7/8 is doing so of their own free will, and any computer you send them can't be used for work.
So you upgrade their computers and ... they're stuck with IE8! :p
In all seriousness, I think it's better and more cost effective to have them switch to a better browser (FF, Chrome and even IE11). There are a lot of Win7 companies that still insist on IE8 as their browser of choice and that costs a lot to support as well, speaking from experience.
I think the point is more for PR purposes and public awareness than it is to actually buy people new computers. If it is, it's a rather good tactic. It gets your attention, doesn't it? ;)
I did a job recently where a legacy site needed to be upgraded to support mobile and tablets. After all the work was done I was informed that the site didn't work in ie6 (the default browser on their work machines) [1]
Luckily firefox was installed on their machines as well.
There was no way I was going back to fix it for ie6 on the budget I was allocated.
[1]: This constraint was never mentioned in initial talks. Fortunately it wasn't a massive deal in the end.
I've found asking up front what level of IE6 support was needed and then listing it as a separate line item in a quote is a good way to get out of supporting it, or at least move from "must be pixel perfect!" to "the main functionality has to work"
I applaud them for moving the web a small step forward. Every minute saved by not worrying about IE7 is a minute that you can spend creating features for standards compliant browsers. As more sites drop support for older versions of IE, more employees will pressure their IT departments for updated browsers.
Maybe one day we will see nothing but evergreen browsers in the logs...
I was saddled with supporting IE8 for a while because our biggest customer (of one of our products) was using it. They made up ~4% of traffic before they finally moved to Win7+IE11.
I think it would be better to find an existing user and execute the scheme - a registration date of "yesterday" and a post count of "1" probably wouldn't qualify you.
It reminds me of the MSFT settlement in the early 2000's where you could get a (I think) $100 check from Redmond. It was somehow "transferable" and a few of my friends bought people's right to redeem the check by doing things like giving out gift certificates or handing out free ice cream. (IANAL so excuse me if I didn't use the proper lingo there)
Brings up an interesting point: cost of buying every customer with IE 7 a new computer < cost of adapting to IE 7 - assuming it's true after all.
Personally, I wouldn't have done an offer like that, as I would see no point in it (other than PR); but then again, I take a ruthless approach to upgrades
I hope it does not turn out to be opposite of what they intended : people starting to use IE7 just to get a new computer. It is called the Cobra Effect (http://en.wikipedia.org/wiki/Cobra_effect)
I work for a large EMR provider. You would be sick by the IE7 traffic at large hospital systems. Think 20%+. The reason is hospitals spend millions of a dollar for one solution. The solution is usually monolithic and takes years to implement.
This is a viral marketing scheme to get some free advertising.
Seeing this kind of viral marketing advertising on hacker news frontpage is sad, this one is not even clever, it's mostly throwing a pile of money towards microsoft.
I disagree. Engineering is all about choosing tradeoffs. Freeways aren't built with a slow lane to support horse and buggy users, because that would be an irresponsible use of resources. For most sites, supporting IE7 would be a complete waste of money.
You got it all wrong, it supposed to be "how offering to buy computers for 1% of our customers is cheaper and more advertising than actually buying an ads campaign ?"
You're right, nursing jobs sites must be so niche they hardly get any traffic. The healthcare industry in the US is tiny, I mean, it's only, what, 16% of the entire US economy? I mean the total expenditure on hospital care in the entire country is only $380 billion or so a year, and employs only about 2.6 million nurses. That's just 1.8% of the US working population. And it's not like nursing is disproportionately dominated by short term contracts, or the provider market that employs them massively fragmented meaning that almost every six to twelve months a career nurse will be jobhunting... yes, 87 nurses looking for jobs, 1 of whom is using IE7, sounds like a perfectly reasonable estimate for the amount of traffic this site with a page 1 google ranking for a search for "nursing jobs" probably gets.
What about IE8-9-10? I mean, I don't care, but my website frontpage still looks wrong in IE10 and I didn't do anything fancy. The overlay doesn't work in IE<10. I mean, IE is a mess in general. I wouldn’t buy a PC to all that use this terrible piece of crap, but at least we can rant about it, no? I mean, they should have said: OK, we take the pain to STILL support this shitty IE, but please stop using IE7 we will buy you a PC if you do.
Great PR, since practically no-one is going to take them up on the offer. If you're on IE7 you're probably on it because MegaCorp's Intranet Application '02 Enterprise Edition doesn't work on anything else. Meaning the new computer will break their LOB application.
It's also possible it won't cost them any money in the long run, if their definition of "customer" is limited to the people posting jobs [1].
[1] http://www.nursingjobs.us/employers/pricing/