>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 y

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