A collection of thoughts, ideas and rants inspired by my career in the fintech and banking industry.

Let's Talk About Signs

If your sign needs a sign explaining the sign then it’s a poorly-designed sign. Let me present a few examples. I’ll start with the intersection at Bloor and Parkside in Toronto shown below. There are four lights in this image: one for the through traffic, one for the cyclists, and two for the right-turn traffic. Both the bicycle signal and the right-turn signal have additional signs adjacent to them explaining what those lights are for. [Read More]
design 

Non-Functional Requirements

Non-Functional Requirements (NFRs) are used extensively in enterprise software to define things like performance requirements and availability expectations but it’s important to be specific about what we’re asking for. I spend a lot of time with my clients helping them understand why the details matter for NFRs so let’s walk through an example to demonstrate what I’m talking about. Let’s assume we’re dealing with a system that is going to process 3-5 million transactions per day with peak volume during business hours at around 50 transactions per second. [Read More]

On Modernization

I’m currently working with a large retail banking client to help them modernize their payments infrastructure. The word “modernize” is used in just about every client interaction. It appears in all the slide decks. It’s part of the business case justification. But modernization is a relative term. The big question is: What does the client mean by modernization? The existing system is a vendor product running in an on-prem application server. [Read More]

Moral Hazard

Is QA a moral hazard?

A moral hazard is when an.. …actor has an incentive to increase its exposure to risk because it does not bear the full costs of that risk. It’s similar to perverse incentives. A perverse incentive is an incentive that has an unintended and undesirable result that is contrary to the intentions of its designers. I have spent the last 6 months working closely with a QA team inside a large financial instutition and have become increasingly skeptical of the value they provide - the development team don’t test as thoroughly as they should because they know that QA are playing backstop. [Read More]
strategy  qa 

QA: The Final Frontier

Your QA process should take hours, not months

QA organisations have come a long way in the last decade or two. In the early 2000s, automated unit testing was just gaining popularity and QA was performed manually by armies of testers. The QA process was time-consuming and arduous, and the testing timelines were the first thing to be compressed when development took longer than planned (as it almost always did). By the 2010s, many applications had moved to a web interface which allowed QA teams to automate some or all of the end-to-end testing using Selenium, or similar. [Read More]

A Good Place To Work

What is it like to work at your company? Think about it carefully. How do your people spend their time? What culture and behaviours do you incentivize? Is it a good place to work? Culture in this context describes how people interact at work, the processes and policies, productivity friction, meeting efficiency, et cetera. Your company’s culture describes what it is like to work for your company, and it has an outsized impact on the type of people your company is able to attract and retain, and whether they feel productive at work. [Read More]

Architecture Vs Engineering

The question is more interesting than the answer

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. [Read More]

The Power Of Constraints

The limitations of physical meetings are a feature, not a bug

Before COVID-19 and ubiquitous work-from-home, we used to have meetings in a room where people would sit around and discuss the matter at hand. The start time had some flexibility because people had to physically move from one location to another, often between floors or buildings. Whiteboards helped focus the conversation. People could interject organically without having to raise a hand like in grade school. Unplanned conversations in the office were common and often more productive than a formal meeting. [Read More]

Antipattern: BFF

Backend-for-frontend

The backend-for-frontend (BFF) pattern is when a backend API is designed specifically for the needs of a frontend consumer. The BFF is intended to make frontend development simple, moving all the complexity and “business logic” to the backend and allowing the frontend to deal with a single backend. The backend BFF API closely resembles the flows and screen designs of the frontend. The initial development experience is often positive. The frontend team can focus on the UI/UX aspects of the application, and the backend team can handle all the downstream integrations and data transformations. [Read More]

Details Matter

Why you need specific requirements

Consider the following statement: Our consultancy operates on a 50% margin. Margin is how much extra the consultancy charges on top of their costs to cover the consultancy’s costs, operating expenses, and profits. Most consultancies have a minimum margin that they’ll consider acceptable when bidding on work. But the details matter when it comes to requirements. A lot. The statement above is subtly ambiguous. How is margin calculated, precisely? I can think of two ways which make sense but result in wildly different profits for the consultancy. [Read More]