Hacker News Reader

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.

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

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

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!

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.

Both of your points are valid.

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.

Fair points there.

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.

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.

Anyway, interesting discussion for sure.

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.

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.

- still cheaper than SAP/Oracle

HAHA! Yes! that shit is ungodly expensive.