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.