Hacker News Reader

Comment by sanguy | Hacker News Reader

Been working on accounting systems in RPG and COBOL since ~1992. I also know C/X86ASM/Pascal/Delphi/VB/Fortran. Never bothered with C++ that much; played with Java a bit but Oracle irritates my bowels so moved away from that.

As mentioned in the article it's good work; but it is also not easy work. You tend to go through cycles of being pushed out to brought back under extreme emergency at any costs to get stuff working. Only for the cycle to repeat. Companies never think of the old guys as the ones to implement the new system - that's a job for the "enterprise experts" - I can't even keep track of how many "rewrites" I've seen in my life fail because of this.

We are the dinosaur club; but it's a club that pays extremely well (high 6 figures a year without working too hard if you are talented and have a good client base and reputation), but like fossil fuel one day it will all be gone ;)

View on HN

> Companies never think of the old guys as the ones to implement the new system - that's a job for the "enterprise experts"

Exactly this is why rewrites fail. The challenge of a rewrite is not in mapping the core architecture and core use case, it's mapping all the edge cases and covering all the end user needs. You need people intimately familiar with the old system to make sure the new system does all the weird stuff which nobody understood but had good reasons that was in the corners of the old system's code. IMHO the best way to approach a rewrite is to make a blended team of experts of the old system and experts of the new technology, and you put a manager in charge with excellent people skills who can get them to work together.

What a ton of people forget : you also need to implement bugs or edge cases the same as in the old software.

More often than not the next developer using the old system worked around it. But never documented it as a bug (or wrong format, it featur! Not a bug!)

What about not doing a rewrite? What about instead refactoring, documenting etc the old system.

Because COBOL is the PHP of the 60s, and mainframes are slow and expensive.

Also, too many of the talents are stuck in a blocked I/O mindset somehow.

Some are wizards though, writing assembly and making raspberry pi sized systems blazingly fast. OK a couple of raspberry pi:s

As a counterpoint, many very well funded and talent rich organizations have failed to retire what TPF mainframes do every day for airlines, banks, and credit card companies.

Cobol isn't involved, but those slow mainframes are.

To be fair, rewriting huge mission critical systems is hard, no matter of what kind of system it is and what you are changing to.

There was never an excuse to not document PHP functionality. Infact, its quite easy to document now, just the same as any other language. Devs simply argue that the 'system is still changing', and so nothing is documented.

Non-Blocking i/o isn't really some miracle new-age programming drug. Doesn't change the equation much.

Our mainframe is expensive but it isn't slow. It's not exactly sitting on the same hardware from the 70's.

The amount of performance (particularly CPU) you get per dollar is very low. Mainframes are all about lots of I/O with ridiculously high reliability and availability, but for an absurd amount of money.

Right, but that's our use case and it also happens to run our legacy applications! IBM's support is also very good.

We're not running our modeling engines and that stuff on it. We have HPC for that.

Mainframes aren't hotbeds of compute power - they are all about the I/O. Your typical COBOL program reads a record, does some moderate processing, and writes a record out. Over and over. So keeping the input and output channels full so processing wouldn't stall was a key design goal.

If you want to move off of COBOL + mainframe, that kind of necessitates a rewrite, doesn't it?

Emulate the mainframe and make a modern abstraction interface over the platform. We investigated this option for some IBM 360 COBOL code for a project I was running. We were a very small team and were market consumers (not implementers) of the original system which got open sourced in a panic. We eventually chose not too - but seriously considered it. If I were the owners (the Fed) I would have.

This doesn't help if part of your goal is to have a system not written in COBOL. Emulating the older hardware and OS gives you an even more complex system that's harder to hire people to work on.

It helps for the first stage - getting the platform onto a more sustainable environment. Once the interface exists and has full coverage, parts of the backend can begin migration without a doomed-to-fail 'big bang' rewrite.

Does it really help? What does it cost to build a trustworthy emulator for an ancient system that you don't own the source for? What would it cost to just migrate your legacy applications to a newer mainframe that IBM supports?

I wasnt suggesting writing an emulator from scratch. I was suggesting emulating the mainframe. Here is what we, specifically, were looking at: https://en.wikipedia.org/wiki/Hercules_%28emulator%29

Don't you then need to pay IBM for the OS anyway? Will they license the OS for this use?

Or did your system actually include the OS source?

For 360, it is now in the public domain: https://en.wikipedia.org/wiki/OS/360_and_successors

Interesting. Thank for the details.

One of the problems with attempting to write interface is the opaque source/consumer problem.

E.g. I'm working on a system that I could hypothetically abstract (I've got access to it, can poke with enough tests and test data, etc).

However. What I don't have is access to code or test injection into any of my sources / consumers. Both of which are expecting all the corner case quirks to be exactly identical and may actually have accreted software that depends on a specific quirk. A specific quirk that I have no way of knowing about. Or may send me something I've never seen and am not expecting because it's a 1:1,000,000 corner case, and we don't have any logging of an example that came through production.

I haven't worked on too much of the heavyweight stuff like you have, but I tend to take the perspective that "a 100% compatible rewrite is impossible." 95%+ maybe, but we're going to have to deal with the <= 5% after it goes to production.

Did you ever pursue writing and dropping a new tailored load balancer / router type application on the incoming data stream such that you could divert a specific portion onto new system(s)?

> we don't have any logging of an example that came through production.

If it's something that's never come through production, it is not already documented anywhere, and it has an occurrence rate of approximately 0.001%, is it really a feature that needs to be replicated?

Sure, because clients will say anything short of 100% success is failure.

(Currently migrating a site of 125k pages of content with oodles of edge-cases)

Yes, but not necessarily a big-bang style rewrite and that's where the difference lies. Big-bang style rewrites have an extremely high failure rate, doing it smart is more work from the start but has a much higher chance of success.

all features and edge cases should have a test. if possible also have tests for all the bugs ever found in the old system. it helps if the tests are not too coupled with the code and are well documented. a test could be making an entry where deb and cred dont match. or trying to enter an extra decimal. and if the system adds two decimals corectly.

Maybe I don't give the rewriters enough credit, but in all honesty, I'd be surprised if they bothered to look that deep into the code and tests before it's already too late. Too often, there's just some handwaving and proclaiming you "don't to it like that in today's software".

I worked a company where they did a rewrite of one of the main systems. My friend said it best when they finally finished and annoyed a lot of their customers. He said, "They fixed the things that were wrong, but they missed implementing all the things it got right."

>all features and edge casss should have a test.

Yeah, but the interesting problem is what happens next. Let's say a test case reveals that there's a flaw in the next-gen system. You fix it. It later turns out that the same flaw exists in the legacy system. What do you do?

Do you revert the fix, or leave it in place?

Yeah, I had to explain to a client once that our new version of their analytics query produced different results because their original SAS code didn't mind referencing variables before they're declared, and so one of the numbers in the analysis used to always be 0.

They did NOT appreciate hearing that they had been running a bugged query for years...

Revert the fix and add it to your backlog. You've got enough to worry about when porting/rewriting, don't add additional dimensions of complexity and risk by trying to change business logic at the same time. Minimize risk by minimizing change...then when the new system is up on its feet, go back and fix all the mistakes you found.

I upvoted that but I suspect that there will never be an opportunity to "go back and fix all the mistakes you found".

At least there never is for me.

I should count all the grains of rice in my lunch, too.

And since the number of old guys available to help is constantly growing, it no longer makes sense to do projects without them. A diverse team makes better products.

Rewrites fail, IME, because the old system was never documented in the first place, and because they are only done when a change that management is not confident can be done in the old system (usually because both technical and business expertise associated with the old system has been lost, and it's being maintained by what amounts to a cargo cult priesthood) is necessary, usually on a firm and fairly short timetable.

Rewrites also fail because the the thing being rewritten is a mess, no specification exists of what it does, and the only regression test suite is deployment into production.

> Companies never think of the old guys as the ones to implement the new system - that's a job for the "enterprise experts"

So true, even for more recent stuff. It's so absurd I always wanted to make a web comic about this. Companies keep ignoring advice of their own developers, and then eventually hire some "technology expert" who is going to implement the same tech their existing staff recommend years ago. Except, of course, the expert has no idea about business processes and user needs, so you end up with a long and expensive train-wreck that results in something barely better than what you had before.

Our company does the opposite. The tech staff recommend against buying bloated enterprise software. They buy it anyway and tell us to make it work. It takes 5 times longer then building something simple and custom and is generally not fun to work with.

We have most platforms from IBM, z (Mainframe), iSeries (AS/400), p (AIX), plus about everything windows.

Moving off core systems (z/i/p) isn't simple mostly because of the amount of data combined with all the custom applications. every attempt to move the apps off the z don't come to fruition because of scope and the fact it just works. the i is increasing its load to pick up from the z and getting a good dose of webfacing and rest services. these are dead simple to implement and many reuse all the existing code.

talent wise, it really hasn't been much of a challenge in Atlanta/Dallas to find those who can support what is needed. the language isn't the biggest road block for many mainframe systems, its the file systems that can trip people. the i is pure DB2 so anyone versed in SQL can use it and RPG looks more like Pascal these days than that three column stuff people normally associate with it.

the one thing many here don't understand is just how many companies are invested in mainframe, i, and large p series systems. don't scoff at these platforms. with modern tools they can be webfaced just fine and the advantage their default coding languages have is they are business math oriented and simple. with modern features and file systems it just comes down to, what is management comfortable with and does it serve the companies needs.

> Moving off core systems (z/i/p) isn't simple mostly because of the amount of data combined with all the custom applications.

I wonder if someone could get away with selling a z/i/p emulator, akin to Wine. (Or perhaps more appropos, Mame, since the machine architecture would differ as well.)

Aren't the modern mainframes something like emulators / hypervisors of the old ones already? (IBM still sells you new mainframes.)

IBM would never license you the OS.

https://en.wikipedia.org/wiki/Hercules_(emulator)

The problem isn't the availability of an emulator, it's licensing the OS you want to use on the emulator.

IBM legally destroyed a business for trying to do that on top of Hercules emulator. You can use the emulator, though, with a licensed copy of their mainframe OS. Common case is you already have license for an actual mainframe then use Hercules for development/debugging/whatever.

The other part of the equation, software aside, is risk -

Anyone using mainframes heavily in the way we are talking about here is probably running something mission critical with lots of $$$ tied into it - and the financial/legal risk of having anything go wrong at all is a huge driver - they want a big company with deep pockets and pages long support agreements backing them, so they can indemnify the other company if there is any problem and shift the blame (and from a personal perspective, cover their own butt). The mainframe using companies also usually have deep pockets, and so even if the mainframe is expensive, it still allows them enough profit margin to support it..

"There is a problem with our IBM mainframe, we have requisitioned a team of 12 people from IBM to investigate and legal is looking into what sort of contractual obligations IBM has if issues aren't resolved" is a much more palatable statement for the fortune-100 CIO to pass along to the CEO than "our IBM emulator seems to be having problems, but the 3 people developing it are on vacation, IT isn't sure if it's an emulator issue or something to do with the new hardware we migrated to run it on 2 years ago, and IBM says they don't support the software when it's run on the emulator. We're calling them again to see if there's some way we can convince them otherwise"

I smiled at your last comment. You're clearly a charming individual :-)

Out of interest, what's the solution here? With your experiences in mind, what are the banks doing wrong from a technological perspective?

I get the impression banks should almost start again on the side, building a completely new bank they then (manually?) move customers over to, or just use to take in new customers whilst waiting for the previous ones to die out. I guess if they built a whole new system, wouldn't it then be a "simple" case of doing a money transfer into the new system?

You can't wait for customers to "die out" as their mortgages will go on for decades. You definitely need a customer's old data in the new system. Now you have to maintain and develop two systems - bugs, banking regulation require constant work. Often the clock is ticking for old systems and asking vendors to provide and maintain ancient tools can be expensive or impossible. You can't "manually" move customers over, you need to "migrate" lots and lots of data - both systems will have huge, completely different database schemas.

While mortgages do go on for decades (typically), people will frequently re-mortgage based on new interest rates.

e.g. in the UK it's typical to sign up for 2-10 year deals, with the interest increasing after these offer periods, meaning people will likely switch to another deal.

So there will be a certain amount or organic churn.

Not enough churn, though. I worked on mortgages for a UK high street bank a while ago, and they were still running the mortgage systems for every bank and building society they'd taken over in their decades of growth, plus a few different attempts at building one system to rule them all.

For an example of how this system switchover looks like, First Bank in the United States just did a whole-system switchover in March, at least for their business customers. They handle my wife's business' banking, which means I do all the paperwork, and it definitely was a pain. Basically it was like signing up for a whole new bank account. They copied over something like only the last 6 months of transactions and some payroll info, but things like automatic bill payments and everything else (even basic online login) had to be set up again.

French banks are actually doing that! SG/Société Générale, a brick and mortar bank that costs a hundred dollars a year, built Boursorama, an e-bank that's free and that gives you $200 if you subscribe. Advantage: SG has too many manned agencies and can't justify preemptively mass-firing them yet – they first need the customer base to dwindle. Better IT, usage of Internet techniques at the core, and drastically simplifying the product line is an intended consequence.

Same happens with other French banks. As a personal PoV, banks' manned agencies provide bad service (from 20x delays to plain mistakes), so I won't cry for them.

Boursorama is not a bank. It's a website to allow people to play on the financial markets ("bourse" = exchange). I think Americans would call that a sort of dealing account.

Obviously, a dealing account has to hold funds and handle transfers. That's not any close to a consumer bank though.

Boursorama Banque is a bank, as in, a normal cheque account, IBAN, VISA card, loans, term deposits and no trading account. Real normal bank. The main Boursorama website is another department, it's not really clear on their website.

It is now also a bank. I own one Boursorama bank and I have account credit card...

Boursorama also owns an Spanish "digital bank" called Self Bank. I have an account there.

As a developer who recently turned thirty, I think about this a lot. I like working in startups, but its not going to fly forever. I'm already the old guy in the room.

Would learning 'ancient' technology be a good career move? These systems aren't going anywhere, right? But the people who know how to maintain them are. Which means that maintaining these system, which already pays well, will pay even better in the future? Or is there something I'm missing here.

it the cost becomes too high or rather if there are uncertainties they will just replace them.

Just hang around - the technologies you learnt when you were 20 will be ancient soon enough.

Yeah, but my impression is they're so ephemeral they might not have a big market share.

Wait you mean Rust and Go aren't going to be around 30 years from now?!

Go probably will be, but it's still a niche. Rust, the jury is still hearing evidence.

You're missing the part where they're being aggressively replaced by Java at every turn and will eventually cease to exist and also these jobs are temporary consulting gigs more popular with retired experts going back to the same bank that fired them years previously.

If you want to be well employed, learn Java and move to the American south where a nice house with a 1/2 acre backyard sets you back less $130k - $200k and they can't find enough qualified IT people. No it isn't a startup or Google, but the pay compared to the average income of $30k lets you live far better than San Francisco as long as you don't mind less things to do in town.

I don't think you need to learn an "ancient technology". There is plenty of work in traditional corporations. You just need to find one that has legs so you can ride it out for the next 30 years. A steady job, 5 weeks of vacation after 15 years, benefits. If your lucky you can become a number and slowly disappear, spending more time doing your own thing. Long lunches, nap in the car, run some errands, etc.

Eventually everyone runs out of piss and vinegar. It's not so bad.

> Long lunches, nap in the car, run some errands, etc. Eventually everyone runs out of piss and vinegar. It's not so bad.

I hate working with people like that, and would hate myself if I did that.

Life is short, how much of it are you willing to give away. That may not resonate with you now but wait until you're in your 40's or 50's and 10-20 years has passed.

I like what I do. I like going to work. I like my company. I like coming home to my baby and tickling his feet. It's life. Being a lazy bum not accomplishing what you want to do shortchanges you and your life as well as the people paying you.

My father in law has a saying: "if you don't like what you do, what are you doing?". And I agree with that.

> I like what I do

You are fortunate. But labeling everyone who "doesn't like what they do" misguided lazy bums is... a bit much.

Most people in this state are slowly recuperating from years of failure while attempting to "do what they like". Usually as a bonus they also have to dig themselves from under a crushing mountain of debt.

As you correctly pointed out - it's life. Though it's rarely as simple as you paint it.

You have a lot to learn.....You'll figure it out eventually.

You should move into management then

No, the stuff you know will be ancient soon enough. I would recommend keeping up with the new way of doing the same ole shit though.

I can't upvote this enough. Your tech stack will be obsolete even though the replacement will be mostly the same and possibly worse. Looking at it differently, imagine being a common lisp diehard starting in the 80's. Every 5 years you look around for something better and mostly anything would be a step back. Your dog died, your kid is in college, you're middle aged, Perl, VB...etc have all come and gone and you're still using lisp lol.

"LISP programmers know the value of everything and the cost of nothing."

- Alan Perlis

I think the question everyone is failing to ask is: what's the interview process like? Do they put you through 4 rounds of whiteboard coding bullshit followed by a coding assessment followed by a pair programming session? If anything, I'd argue the interview process for such a nice role should be the most rigorous because you can't rely on auto-complete-by-stackoverflow.

Doubtful. I'd bet a lot of the people who can do this work wouldn't be interested in a whiteboard interview. If you're fishing in a small pond for people that can maintain your legacy code, there's going to be a lot less bullshit in the process.

Whiteboard interviews have their place, I'm sure. This isn't one of them.

I'm pretty sure with these kinds of systems, if you can repeat about 10 nouns relevant to working within a mainframe environment like this, you're hired.

I've considered it, seriously even. I could go off, contract for large hourlies, probably get paid a lot more than I do now as a more junior exec with a lot less stress (and when I first moved into management, I had the same thoughts). If you have the skills and reputation, this is an area where you write your own ticket. If I were closer to retirement age instead of in my mid-30's, I think I'd be doing it.

I guess software is so ingrained into companies these days---and banks were particularly early adopters, that the best chance of a rewrite of a company's software is to start a new company.

A new company whose processes for example don't have all these interdependent edge cases (yet). The domain will start pushing edge cases on the new company too sooner or later, but that knowledge still has a chance to diffuse---and lots of newer companies these days are probably better at avoiding small bus factors.

>> Companies never think of the old guys as the ones to implement the new system - that's a job for the "enterprise experts"

Too often the old guys simply re-create the old system using the old methods in new software, and you end up with all the same problems as before.

In a perfect world, the two would work together.

> high 6 figures a year without working too hard

Wow, like $800-900k?

It's not unheard of. But you must understand that these are people that have a pretty decent job security in an often huge codebase that has been aquiring cruft for 30 years in language most people don't understand. I would like to be able to claim that the code is good, but some of the people writing it in the first place were not programmers. It is not strictly bad, but some parts are just mine fields.

A bit related:

I spent 2 years of my life on a C codebase written by mathematicians that would much rather have written it in APL. I don't know if you have seen C written as APL, but that is 2 years of my life I will never get back. I left for a lesser paid, more fun job. Upon leaving the manager offered me a 60% pay raise (yup, I should have had higher demands, but at least I proved myself :) ).

Unless you enjoy torturing yourself, legacy COBOL programming is not very rewaeding, and at least in Sweden, most of it is slowly being moved to other languages.

Best story I've heard is one of the old programmers commenting his COBOL code in latin. It was a different time...

Malus est?

I feel like that's a play for job security more than anything else.

And different times: these days with Google Translate Latin doesn't add much to your job security.

It's common practice in Vatican Bank.

How do you know? Have you seen one?

The ATMs in Vatican City have Latin as their main language, so it's not a huge stretch...

https://commons.wikimedia.org/wiki/File:Vatican_latin_atm.jp...

"Mea culpa" over and over?

> COBOL programming is not very rewaeding, and at least in Sweden, most of it is slowly being moved to other languages.

Which would imply that there's a demand for people who know both COBOL, and whatever's the popular migration target for such systems these days (I assume Java?).

Migration target like visual cobol (not a joke). Just look at those smiling hipsters writing cobol.net on their laptop.

https://www.microfocus.com/products/visual-cobol/visual-cobo...

I can't wait until I can compile Cobol for webasm

Nah, go with terminal apps in Visual COBOL distributed as Electron apps.

https://xtermjs.org/ is here for you.

Oh my goodness... why do I keep making jokes about how a ridiculous world would function and then reality is already halfway there?! It's been happening too often past two years.

This seemed surprising to me on the first read, but it makes sense. An average senior software engineer probably makes ~$120K in US. They often work on systems that aren't in any way critical and are more or less replaceable. Anything in COBOL these days is by definition is crucial and highly expensive infrastructure. The talent pool to work with that tech is small. They are by definition very experienced and probably highly specialized even within that pool. So upper six digit salary actually makes sense.

To be honest, the idea of companies paying through their noses because of decades of short-term thinking makes me smile. Karma in action.

I expect he meant the high range of 100K-200K. It's a colloquialism I hear periodically. I took it to mean $180K-$200K.

How can "high 6 figures" mean high 100-200k? Ugh, I hate english.

It can't. This is not reasonable English, it's (presumably) a misspeak by the OP. People make these kinds of mistakes in every language.

It is highly unlikely that that the OP is making $800k/yr consulting as a programmer. That's $400/hr sustained for more than a year of fulltime work.

$800k/year is possibly unusual, but these are unusual people. I see nothing unlikely about a highly skilled contractor with 30 years of experience, a good network and in the right location to be pulling down $800k/year.

Do you know anyone who does? "Without working too hard"?

The chance that the OP is billing $800k/yr is vastly smaller than the chance that the OP used a bad figure of speech. The number of technology professionals who can sustain $400/hr billing for a full year is tiny. The number of technology professionals who are bad at communication is huge.

Bayes' Theorem is relevant here.

I know someone who makes half that and who is utterly unremarkable (nice guy, competent - but unremarkable, he's just played his card very well. Not playing politics, but being a consultant, not FTE, in a lucrative niche, and possibly having a nose for ending up on good projects). So I can believe that a tiny number (which is what we're talking about, they can make this much exactly because there is only a tiny number of them) can make this much.

"Without working too hard" is quite subjective. I suspect they are quite disciplined and works quite hard, but are very rarely in the office after 5, nor working much more than 35-40 hours a week.

As to (bad) communication, $200k/yr is high but unremarkable for SV/NYC careerist professionals. The notion that someone with decades of rare, in-demand experience should somehow be capped at what a (lucky) 35 year old engineering manager makes is just silly.

There is a steep power law in bill rates. It is not twice as hard to get $400/hr as $200/hr, but orders of magnitude harder. And my observation - as someone who bills more than these numbers sometimes - is that the higher the rate, the shorter the gig.

You have to look at this probabilistically. Contract programmers taking home $800k/yr are very rare, but folks misusing "upper six figures" to mean $180k are common. I'm not a gambler, but I would happily place bets on the meaning of the OP. This is classic Bayes' Theorem.

The fact that everyone here is jumping into this thread to justify how it could be possible probably says a lot about the psychology of HNers.

And the fact that everyone else is jumping in to categorically deny that its possible says a lot about the psychology of other HNers.

Nobody is denying the possibility that the OP spoke correctly. The realm of possibility is broad.

We can, however, assume with a fairly high degree of confidence that he misspoke.

If the systems they build and maintain generate magnitudes larger revenue for their overload owners, then why not 800k salaries. Time for labor to actually be valued.

It's not unlikely at all for a highly specialized skill set. Speaking from experience.

This isn't your average developer banging out Rails or Swift apps. This is extremely specialized knowledge of huge and arcane systems that are decades old. Entirely different ballpark in terms of knowledge and skillset.

Not to mention the value to the businesses running these systems. $800k doesn't even qualify as an expense to a lot of these companies relative to what they lose if the system goes down. They probably think they're getting a deal.

While I agree, I heard a similar thing on the weather (here in the UK, in degrees Celcius), when the weather woman said we would be in "mid double figures" tomorrow, clearly meaning around 15 degrees, not 50!

They don't use "mid-teens" in the UK?

Yeah, we do. "Mid double figures" might make sense in the context of use, but my first evaluation of that phrase isn't a value less than 20.

Sounds like it was clearly a mistake, but as you mentioned in a very specific context, with a specific range of likely values (temperature near sea level on Earth) I could see how it could make sense.

Yes they do, but I guess she just mis-spoke (for those in the UK, this is Carol Kirkwood on the BBC)...

I wouldn't call it that, but if I had to for some reason I'd go with percentiles. Within the group of people who make 100-999k, 200k puts you at about the 80th percentile. I think 80th percentile is good enough to call "high".

i feel like the terms quarter- or half-million (or million itself) are what people would use to describe salary once they've busted the "6-figure" descriptor where the first figure is implicitly "1".

"half-million" is much more impressive sounding than "mid 6-figure" salary.

I think since he wrote 'pays extremely well' it could mean 800k+

I don't think so. TFA references a rewrite that cost $750M over five years. Paying three or four experts $800k/year to keep it running is chump change in comparison.

You can make $250/hr consulting for mobile app development. I have no doubt an expert in some ancient Cobol-based banking software can set their own price. When your entire business stops when it breaks paying $1000/hr is chump change by comparison.

Sounds like you should start an "enterprise expert" consultancy that knows what it's doing. Seems like a good opportunity.

great idea. Or an expert network as many are self employed.

Go for it, if you like death marches that will just fail.

The real trick to software consultancy nirvana is to find the big whales paying big money for what are just kiddie apps.

Reply on news.ycombinator.com