csmithuk

(yes this is sarcastic).

I would lock my doors too. Only because I know two people who got carjacked.

People queue at your door if you have these skills.

Mediocre programmers create a lucrative market for unicorn shit as I was once told.

I use a singleton on every project which is OO based but it only ever holds the service locator/container.

Asp.net MVC is a fine real world example of how to fuck up Singletons (routing dictionary, global action filters etc). Totally stinks and is coupled like glue.

Cost of software and hardware for that was £0!

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.

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.

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.

http://www.z80.info/zip/zaks_book.pdf

Wonderful book from which a lot of knowledge is applicable to other architectures straight away. It teaches you about planning, control structure implementation and the maths behind it all as well.

This isn't really an option for a lot of people.

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.

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.

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).

[1] Apart from IE.

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.

It still feels really fast if you don't use X.

Then suddenly... click.

Suddenly, in my mind appeared an abstract model for it. It was complete and possible for one person to understand.

Since then I understand what I'm doing rather than know how to drive the compiler.

That has never happened for any other language I've written and that includes Z80+6502+X86 ASM, C++, C#, VB3-6, PDS7, ksh, Python, Perl and PHP to name a few. Assembly is close but not abstract enough.

Enlightenment is probably the best word to describe it.

1. Performance reasons. For example: zero copy data structures, mutable data structures, controlling data locality.

2. Direct memory mapped hardware access. For example: device drivers, kernel, embedded systems, microcontrollers.

3. Bitwise and machine specific conversions. For example: endianess conversions.

4. Structure type coercion. For example: object systems, tagged data structures etc.

I primarily write C# (for cash reasons) but my heart will always be with C.