A Feedback Loop from Matt Crooks

My framework for building applications in an Uncomfortably Simple way was shared last week, and I have received some good feedback - thanks to everyone who sent me something! My friend Matthew Crooks sent me the most detailed feedback so far, and I wanted to share more broadly.

Rapid feedback loops are the best way to improve a product, but also an idea. I encourage engineering managers and leaders to capture their methods & mechanisms in writing and share with peers for feedback! If you’re a FinTech CTO then one such community of peers is https://f-intech.com.

Thanks Matt!

A Feedback Loop from Matt

I think we’ve shared many of the same experiences over the years so I thought I’d send you a couple of thoughts that emerged as I read your article.

A recent example of starting simple and iterating is one of my businesses in Aus. They just completed a Pilot for a customer (part of a university) for an online learning platform. This was built completely in WordPress using off-the-shelf packages. The project was hugely successful and they are now looking to build a custom platform (not on WordPress), but it scaled easily to 1000 users and now they’re in a position to take it to the next level having validated the idea.

“For example, if a feature is only going to be used occasionally (especially if you don’t have users yet) such as an account termination or a year-end process, then perhaps it can be descoped and handled manually by an operations team”

Agree, this works in the early years of a start-up. However, this can quickly blow out the resource requirements in operations if this practice becomes ingrained in the culture. I regard this as a form of Debt that needs to be repaid as an organization grows. However, in my experience, the debt is never repaid as the push is more often than not for new features to grow the top line and not operational efficiency. I agree to get a product off the ground this is the right approach. But ignore back-office efficiency and you'll quickly find yourself in P&L Hell; that is, the top line might grow but your bottom line will not.

Microservices

I agree, Prototypes and even V1 should rarely be developed with such a complex architecture. Instead a Modular Monolith is much quicker to iterate on in the early days.

Compliance

Coming from a wealth management background I can relate to this. Further to your comments I’d advocate for early stage companies to take an approach where, once a minimum baseline is established, the risk management frameworks are strengthened in line with growth. That is using a metric like customer number or AUM for example. For example $0-10m - Light frameworks, basic monitoring by founding staff… all the way to $100m-$10b Established Risk and Governance Oversight Committee, dedicated resources, Annual Independent Audits and regular engagement with Regulators.

Making Iteration Easier

I am a massive fan of automated testing. I just ran a workshop here in Manila yesterday and built unit tests for a new component in the workshop. I could tell it was a foreign concept for some of the developers.

That said, if prototypes are to be thrown away, don’t build unit tests as it is wasted effort, because your code structure is likely to change as you move to V1 development. I also like Test Driven Development and Red-Green development. I’ve found myself capturing business requirements this way while the business user is in the room.

Should_Refund_Half_OriginalAmount() {
	OriginalTransaction.Amount = 110
	Expected = 55
	Actual = target.RefundCustomer(originalTransactionId)
	Assert.Equals(expected, actual)
}        

The idea is we write the test first based on a user story, and it fails (“Red”) as there isn’t code to handle the requirement.? Then we implement the function, and the unit test passes (“Green”).

But again, don’t do this for prototypes or even pilots.