The second part of the article makes it clear that the author has never worked in online banking (I have), and possibly any other complex domain. > Have you ev

The second part of the article makes it clear that the author has never worked in online banking (I have), and possibly any other complex domain. > Have you ever heard about those three web engineers who figured out that secure online banking is actually quite an easy problem to solve? > The storage and transfer of numbers is not a particularly hard problem. These quotes are so incredibly disingenuous that make me question any advice OP has to offer. First, banking is quite a complex domain, and it's complexity increases exponentially with the kind of services that you offer. Second, banking is a highly regulated industry, which makes everything why harder than "it should". In fact many "neobanks" have appeared in the last decade, and this is usually their biggest hurdle. Third, online banking needs to deal with quite a few hard technical challenges. That's why the likes of Monzo, Starling or Revolut often given tech talks. So no, imaginary requirements weren't the root cause of bad software when I worked in banking. A 20+ years old big ball of mud, inability to pay off any tech debt (unless you wanted to get literally yelled at in front of the entire team), flaky and severely insufficient tests, and a very toxic working environment were all causes of bad software.