4 ms·

> Why the West is reluctant to deny Russian banks access to SWIFT Possibly because the banks using it don't really understand it. After succesfuly delivering o

> Why the West is reluctant to deny Russian banks access to SWIFT Possibly because the banks using it don't really understand it. After succesfuly delivering one project at Credit Suisse I was charged with implementing a SWIFT interface, but no-one, and I really mean no-one, could tell me what such an interface should look like, or how it should be used. After a lot of mucking around at and around Canary Wharf (which did at least get me to the top of the Canada Square building a couple of times - remarkably shoddy indoors, at least on the CS floors) I came to the conclusion that this was a project that never could work, and left.

phkahler 5y ago
I see this more and more. When software infrastructure become mature and stable, the people who built it eventually leave or retire. You end up with systems that people use and occasionally modify, but the real understanding is gone. The ability to make big changes is reduced. Knowing what secondary effects a change may have is nearly impossible. But you can keep right on using it just fine.
- hackerfromthefu 5y ago
  It boggles my mind the endemic shortsigtedness regarding deep knowledge of systems that is shown by software owners. Case in point, higher salaries for new hires without deep knowledge, and lack of retention salaries for those who have years of history with systems. Another example, getting contracted consulting developers to build business critical systems, without locking in retainer arrangements to ensure continuity of deep support knowledge.
  - duped 5y ago
    I mean it doesn't help that the developer class has a giant incentive not to make things that last
    - no_wizard 5y ago
      incentives tend to follow other incentives. As noted above, the best way in the industry most of the time is to move companies to get better compensation, and sometimes better workplace conditions as well. Companies don't incentivize people staying around. At bigger companies sometimes - not always though - you can make progress in these areas by getting promoted, however that only works for N percent of a workforce at any given place. If companies incentivized retention with realistic paths to better compensation and growing your career, they'd see lower turn over with these systems. There's a reason that in recent times there were newsworthy stories about companies giving out retention bonuses and salary increases when some sticks started to plateau / lose value (and therefore RSUs not retaining value), because its relatively rare
      - duped 5y ago
        That's making a giant assumption that the employer considers software development to be a core operation in their business. For a lot of companies, paying for software is like paying for a copier - you buy the thing to sit in the office, maybe you pay for X years of maintenance, and when it stops working you buy another one. Maybe at a business with tons of copiers you'll have staff trained in how to maintain and repair them internally, but that's never going to be considered a core operation. A lot of businesses treat software like copiers; they don't want to build it (because they don't consider themselves "tech"). And for a lot of the developers that make or maintain this software, there is little incentive to build it to last.
        no_wizard 5y ago
        That's exactly my point. They don't have an incentive structure so that it is not treated like copiers. We are definitely on the same page here, in that sense. When I can only get 6% increases in a year to my base compensation by staying at a place and get 10, 20 sometimes even 30 % by leaving for a competitor doing a similar job, the calculus isn't hard, all things being relatively equal. This is just an unfortunate reality, and its true beyond even tech. I have a few friends with MBA's (accountants / finance) and they say similar things about their jobs too, switching every few years to get better compensation and once their growth starts to plateau they just rinse and repeat.
- zabzonk 5y ago
  > the people who built it eventually leave or retire. Exactly right. At Credit Suisse I asked questions of the back-office people regarding the proposed interface that were to use it and notionally understanding it, such as: - what are you going to do with it? - how are you going to access it? - why are you going to access it? - what's the security to it? And so on, to no avail. I had really long given up being a systems analyst, but I had to start again, to little avail. And I had the full (crap) SWIFT message documentation. God help us if we try to bring Putin down via this route.
- int_19h 5y ago
  (Vernor Vinge, "A Deepness in the Sky") "There were programs here that had been written five thousand years ago, before Humankind ever left Earth. The wonder of it — the horror of it, Sura said — was that unlike the useless wrecks of Canberra’s past, these programs still worked! And via a million million circuitous threads of inheritance, many of the oldest programs still ran in the bowels of the Qeng Ho system. Take the Traders’ method of timekeeping. The frame corrections were incredibly complex — and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth’s moon. But if you looked at it still more closely … the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind’s first computer operating systems. So behind all the top-level interfaces was layer under layer of support. Some of that software had been designed for wildly different situations. Every so often, the inconsistencies caused fatal accidents. Despite the romance of spaceflight, the most common accidents were simply caused by ancient, misused programs finally getting their revenge. “We should rewrite it all,” said Pham. “It’s been done,” said Sura, not looking up. She was preparing to go off-Watch, and had spent the last four days trying to root a problem out of the coldsleep automation. “It’s been tried,” corrected Bret, just back from the freezers. “But even the top levels of fleet system code are enormous. You and a thousand of your friends would have to work for a century or so to reproduce it.” Trinli grinned evilly. “And guess what — even if you did, by the time you finished, you’d have your own set of inconsistencies. And you still wouldn’t be consistent with all the applications that might be needed now and then.” Sura gave up on her debugging for the moment. “The word for all this is ‘mature programming environment.’ Basically, when hardware performance has been pushed to its final limit, and programmers have had several centuries to code, you reach a point where there is far more significant code than can be rationalized. The best you can do is understand the overall layering, and know how to search for the oddball tool that may come in handy … … And he learned something about mature programming environments that Sura had never quite said. When systems depended on underlying systems, and those depended on things still older … it became impossible to know all the systems could do. Deep in the interior of fleet automation there could be — there must be — a maze of trapdoors. Most of the authors were thousands of years dead, their hidden accesses probably lost forever. Other traps had been set by companies or governments that hoped to survive the passage of time."
leto_ii 5y ago
I've heard similar stuff about the Dutch iDEAL [1] system. It's probably true of a lot of complex software systems. These things always remind me of Jonathan Blow's talk (I think here [2]) about the collapse of civilization. [1] https://en.wikipedia.org/wiki/IDEAL https://en.wikipedia.org/wiki/IDEAL [2] https://www.youtube.com/watch?v=ZSRHeXYDLko https://www.youtube.com/watch?v=ZSRHeXYDLko

phkahler 5y ago

I see this more and more. When software infrastructure become mature and stable, the people who built it eventually leave or retire. You end up with systems that people use and occasionally modify, but the real understanding is gone. The ability to make big changes is reduced. Knowing what secondary effects a change may have is nearly impossible. But you can keep right on using it just fine.

hackerfromthefu 5y ago
It boggles my mind the endemic shortsigtedness regarding deep knowledge of systems that is shown by software owners. Case in point, higher salaries for new hires without deep knowledge, and lack of retention salaries for those who have years of history with systems. Another example, getting contracted consulting developers to build business critical systems, without locking in retainer arrangements to ensure continuity of deep support knowledge.
- duped 5y ago
  I mean it doesn't help that the developer class has a giant incentive not to make things that last
  - no_wizard 5y ago
    incentives tend to follow other incentives. As noted above, the best way in the industry most of the time is to move companies to get better compensation, and sometimes better workplace conditions as well. Companies don't incentivize people staying around. At bigger companies sometimes - not always though - you can make progress in these areas by getting promoted, however that only works for N percent of a workforce at any given place. If companies incentivized retention with realistic paths to better compensation and growing your career, they'd see lower turn over with these systems. There's a reason that in recent times there were newsworthy stories about companies giving out retention bonuses and salary increases when some sticks started to plateau / lose value (and therefore RSUs not retaining value), because its relatively rare
    - duped 5y ago
      That's making a giant assumption that the employer considers software development to be a core operation in their business. For a lot of companies, paying for software is like paying for a copier - you buy the thing to sit in the office, maybe you pay for X years of maintenance, and when it stops working you buy another one. Maybe at a business with tons of copiers you'll have staff trained in how to maintain and repair them internally, but that's never going to be considered a core operation. A lot of businesses treat software like copiers; they don't want to build it (because they don't consider themselves "tech"). And for a lot of the developers that make or maintain this software, there is little incentive to build it to last.
      - no_wizard 5y ago
        That's exactly my point. They don't have an incentive structure so that it is not treated like copiers. We are definitely on the same page here, in that sense. When I can only get 6% increases in a year to my base compensation by staying at a place and get 10, 20 sometimes even 30 % by leaving for a competitor doing a similar job, the calculus isn't hard, all things being relatively equal. This is just an unfortunate reality, and its true beyond even tech. I have a few friends with MBA's (accountants / finance) and they say similar things about their jobs too, switching every few years to get better compensation and once their growth starts to plateau they just rinse and repeat.
zabzonk 5y ago
> the people who built it eventually leave or retire. Exactly right. At Credit Suisse I asked questions of the back-office people regarding the proposed interface that were to use it and notionally understanding it, such as: - what are you going to do with it? - how are you going to access it? - why are you going to access it? - what's the security to it? And so on, to no avail. I had really long given up being a systems analyst, but I had to start again, to little avail. And I had the full (crap) SWIFT message documentation. God help us if we try to bring Putin down via this route.
int_19h 5y ago
(Vernor Vinge, "A Deepness in the Sky") "There were programs here that had been written five thousand years ago, before Humankind ever left Earth. The wonder of it — the horror of it, Sura said — was that unlike the useless wrecks of Canberra’s past, these programs still worked! And via a million million circuitous threads of inheritance, many of the oldest programs still ran in the bowels of the Qeng Ho system. Take the Traders’ method of timekeeping. The frame corrections were incredibly complex — and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth’s moon. But if you looked at it still more closely … the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind’s first computer operating systems. So behind all the top-level interfaces was layer under layer of support. Some of that software had been designed for wildly different situations. Every so often, the inconsistencies caused fatal accidents. Despite the romance of spaceflight, the most common accidents were simply caused by ancient, misused programs finally getting their revenge. “We should rewrite it all,” said Pham. “It’s been done,” said Sura, not looking up. She was preparing to go off-Watch, and had spent the last four days trying to root a problem out of the coldsleep automation. “It’s been tried,” corrected Bret, just back from the freezers. “But even the top levels of fleet system code are enormous. You and a thousand of your friends would have to work for a century or so to reproduce it.” Trinli grinned evilly. “And guess what — even if you did, by the time you finished, you’d have your own set of inconsistencies. And you still wouldn’t be consistent with all the applications that might be needed now and then.” Sura gave up on her debugging for the moment. “The word for all this is ‘mature programming environment.’ Basically, when hardware performance has been pushed to its final limit, and programmers have had several centuries to code, you reach a point where there is far more significant code than can be rationalized. The best you can do is understand the overall layering, and know how to search for the oddball tool that may come in handy … … And he learned something about mature programming environments that Sura had never quite said. When systems depended on underlying systems, and those depended on things still older … it became impossible to know all the systems could do. Deep in the interior of fleet automation there could be — there must be — a maze of trapdoors. Most of the authors were thousands of years dead, their hidden accesses probably lost forever. Other traps had been set by companies or governments that hoped to survive the passage of time."

leto_ii 5y ago

I've heard similar stuff about the Dutch iDEAL [1] system. It's probably true of a lot of complex software systems. These things always remind me of Jonathan Blow's talk (I think here [2]) about the collapse of civilization. [1] https://en.wikipedia.org/wiki/IDEAL https://en.wikipedia.org/wiki/IDEAL [2] https://www.youtube.com/watch?v=ZSRHeXYDLko https://www.youtube.com/watch?v=ZSRHeXYDLko