Development

Payments Canada published an opinion piece outlining how they think ISO fits into the payments ecosystem.

The ISO 20022 standard provides a common language for Financial Institutions to use when communicating with each other. It brings consistency and well-considered data structures to interfaces that previously had none.

ISO 20022 defines a catalog of messages to standardize data exchange in the finance industry, and it is gaining popularity in Payments.

Here in Canada, Interac updated their APIs to support ISO 20022 several years ago. FedWire in the US will be rolling out ISO 20022 support in summer 2025, and Zelle is following suit with its integration to The Clearing House’s Real-Time Payments network.

But it’s not a standard despite what the name implies.

I wrote about DRY configs many years ago but astonishingly my clients don’t seem to read my blog. I mean, who even has a blog these days anyway?

Externalized application configs have a way of multiplying like rabbits to the point where people become afraid to touch them at all, let alone apply the DRY principle to them. The proliferation of poorly-designed configuration files in Enterprise Java systems is appalling, and the situation is compounded when an external configuration system like Consul or Spring Cloud Config is added to the mix.

I’m working for a client that has separate teams for architecture and engineering. Architecture is responsible for defining the long-term direction of the platform and engineering is responsible making that dream a reality, in addition to their day-to-day sprint work. Each engineering pod has a representative from architecture as one of its members but their role is mostly about producing documents and interfacing between the two teams - they don’t touch the code at all.

One thing that development teams constantly struggle with is striking a balance between building features, fixing bugs, paying down tech debt, and embarking on more ambitious activities like replacing core components in their architecture. It’s also something that Agile tries to solve but I’ve never seen it solved to everyone’s satisfaction.

And I think it’s because many Agile Product Owners are focused on the specifics of what features they’d like to see built instead of setting the direction for the dev team and letting them figure out how to get there. They allocate some random percentage of the sprint to tech debt just to keep the team happy but it’s hard to make significant changes with 10% of the sprint capacity.

Software should do one thing, and do it well. Each piece of software should have a clearly-stated goal that is used to determine whether a particular feature should be implemented or not. When a proposed feature does not fit with the software’s stated goal then don’t implemented it. Just don’t.

Like adding source control to your product. We already have several perfectly good source control systems. Building your own custom source control system into your product is never a good idea. Your implementation is unlikely to be as good as the standalone products like Git, Mercurial or Subversion, and it’ll probably make it difficult for me to use my source control system of choice.

I’ve been working on re-platforming the online banking system for a Canadian retail bank for over two years. Leading up to the initial launch, The Business decided to defer a few features to the next release which was scheduled for about a month later. We created a release branch to support defect fixes found in testing, and the development team continued adding features to the develop branch. Bug fixes from release were merged into develop regularly. The process was working.

Michael Feathers says that legacy code is any code without tests but I’d go a step further and say that legacy code is any code that is still running even though the original developer(s) are no longer working on it. And there is certainly plenty of that in financial institutions. There are other characteristics too, such as:

• unreproducible production environment
• incomplete source control
  • missing files
  • ‘master’ fails to build
• no automated build process
• no release process
• few or no unit tests
• no way to run or test the code on a developer workstation
• little or no documentation
• none of the original developers available

I am presently working on a codebase that checks all of the above boxes and it isn’t even that old but instead of dismissing it as an unmaintainable mess I have changed my mindset and have started referring to it as Heirloom Code.