Turpentine
Top Three Summer Series - Part 6
“When art critics get together they talk about form and structure and meaning. When artists get together they talk about where you can buy cheap turpentine.”
— Pablo Picasso
Welcome to the 2024/25 Top Three Summer Series. This is the sixth and final post, leading up to the launch of my new book How To Be Wrong in just a few weeks time. Links to the full series are below. Enjoy!
Aim … Fire 8th December
Feedback Loops 15th December
A sky full of stars 22nd December
Invisible technology 5th January
Getting ahead 12th January
Turpentine 19th January
🧨 T-minus 3, 2, 1
Today is a milestone: pre-sales for my new book are available now.
I've created a special "First 500" limited edition of the book, which will be signed by me and individually numbered. I'll even add a custom message on request.
As the name suggests, this promotion is limited to the first 500 copies, so get in quick. Once they're gone they're gone.
For the pre-sales, we've also created discounted bundles, to make it easy for you to buy a copy for everybody on your team:
Buy 2x copies, save 10%
Buy 3x copies, save 10%, with free t-shirt
Buy 5x copies, save 10%, with free Ctrl-Z cap
Buy 10x copies, save 20%
Mix-and-match the bundles to get the exact number of copies you need and then decide who gets the swag!1
Maybe I've lost my mind, but there are also some larger bundles which include some never-to-be-repeated money (usually) can't buy offers:
Buy 50x copies, and I'll join a zoom call
Buy 100x copies, and I'll come and visit in person
These offers are strictly limited and are a chance to get some of my time to spend with you or your team. If you're interested, don't delay.
⏮️ Rewind
In Part 3 of the Summer Series, I talked about the conversation I had, on stage, with Joel Little at the Sunrise festival in Wellington last year.
I love this conversation format, and recommend it to all conference organisers. Find two interested and interesting people and let them chat. It’s nearly always better than a prepared keynote, or a forced interview.
For example, and as a bit of nostalgia, here’s a throwback to a similar conversation I had with Trade Me founder Sam Morgan at Webstock way back in 2008. The video is a bit janky, and deteriorates later in the recording (frankly, given how old it is, I’m a bit surprised it’s in colour!), but I think you might still enjoy it.
From 4-6 March I’ll be in Adelaide speaking at _SOUTHSTART 2025.
I’ll be “in conversation” with Matt Allen, the founder of Tractor Ventures and one of the fascinating people I get to work with and invest alongside. I’m sure he’ll have some interesting questions for me and I definitely have a few I’m looking forward to throwing at him.
Maybe I can convince a few more Kiwis to pop over with me, and enjoy some late summer in South Australia? You can get your tickets here: https://bit.ly/4hy24LM
🎭 Startup Theatre
When I posted a similar promotion for the Sunrise festival on LinkedIn earlier in the year, I got this (I think) tongue-in-cheek response from Philip Fierlinger:2
I mean, he’s 100% right. As I say in the book:
I’ve attended and even spoken at many startup events over the years. The irony isn’t lost on me when I say “prioritise talking to customers” to a room full of people who are prioritising listening to me rather than talking to their customers.
As I replied to Phil back then, “Come as a music fan, not a startup founder!”
The key, I think, is captured in that Picasso quote above, which I’ve heard independently from several different people over the last couple of months. Perhaps it’s now a meme, and the next step after that is it gets adopted by the exact people it’s intended to criticise, but there is some important truth in it about the fundamental difference between a gala gallery launch and a meetup of artists.
The question we should ask about what I call “Startup Theatre” is whether it’s building up confidence more than it’s building up competence. It’s fine to be a cheerleader and to make people feel energised and excited - that’s important. But always remember, cheerleaders are for the fans watching in the grandstand, not the players in the arena.
🚧 Technical Debt
When we work on a startup, it’s important to remember: everything is legacy.
One of the delightful things about writing How To Be Wrong has been dredging up memories of the very early days of ventures like Trade Me, Xero, Vend and even Timely - some now 20-plus years old. As someone who rebuilt Trade Me twice, I sometimes wonder (nervously) if any of my original code is still running there.
We are living in the good old days. The brand new code we’re writing today (or prompting Cursor to write, more likely) will soon enough be the “spaghetti” that others are pleading to throw out and rewrite.
Software engineers often complain about “technical debt” - describing the costs that will be incurred in the future as a result of shortcuts taken today. That begs the question: does it ever make sense to borrow from the future like this?
We readily accept that mortgage debt is a useful tool to help build equity ownership - few people would suggest saving the full cost of a house before purchase, for example. Despite paying back multiples of the borrowed amount, we understand the trade-off - the benefit of living in the house while making repayments, plus potential appreciation in value in the meantime. And as we discussed last week, many New Zealanders are particularly susceptible to this thinking, with their unwavering belief that property values will always increase.
So why don't we think about technical debt the same way? Why do we never talk about technical equity, or ever consider where and when and how this accumulates?
When we build something new (hello, world?) the technical balance sheet is straight forward: The technical asset we’re building is the software. The technical equity, on the other hand, is the value we get from having that software.
But, as we write more code, we have hard decisions to make. It’s generally impossible to write all of the code we need as soon as we need it. We have to trade-off between completing every feature to a high quality standard and partially completing more features. Remember, we can make things good, fast, or inexpensive - but we can only pick two out of three. In startups, the choice is often between building everything to a high standard, or partially completing more features that let us learn from customers sooner.
In early-stage startups, there is nearly always a lot of what I call Flintstoning: the code isn’t fully tested, and is full of bugs; the code isn’t fully documented, and so can’t be easily picked up and modified by others later; or we have intentionally cut corners to go faster - there are usually multiple ways to build the same feature, and when speed is of the essence we will typically choose the fastest to implement, which is often not the easiest to extend or maintain. Often all three of those things are true! Just like the cartoon, there are human feet powering what appears to be a car.
When faced with an ageing, messy and complicated codebase, it’s common for software developers to think: we need to start again, and this time build it properly. That is nearly always a mistake, because embedded in that existing code are all the little lessons hard-earned as it was written and maintained over time. Trying to replicate those in brand new code tends to be more difficult than software teams ever appreciate.3
But if we take a balance sheet view then the questions would be different: How much technical debt can we service before it becomes a risk? How much technical debt is optimal?
The factor, which is nearly always overlooked by technical teams, is the payback period: If we invest up front in high quality code, how long is it before we get returns on that investment? One consequence of taking much longer to launch is it’s also much longer before we get any feedback from customers about the things we’re building. And, if we stop now and refactor everything, when do we get back to the path we were on previously? Managers often underestimate the immediate costs of working on a messy code base. But engineers are also often wildly optimistic about how quickly and easily they can repay technical debt, and also about how much more efficient they will be in the future given the opportunity to architect everything perfectly now.
Meanwhile, customers rarely care either way.
Rather than falling into the easy trap of complaining about technical debt, I recommend you keep these three things in mind:
Given the choice, an engineer will always prefer to write new code than to try and read existing code. The code you struggle to read probably isn’t as bad as you think. And the code you write probably isn’t as good as you think. Future generations of engineers, trying to read the code you write today, will struggle with that exact same asymmetry.
As Peter Norvig (apparently) said, “All code is liability”. Every line of code we write is a prediction about the future - and like all predictions, it accumulates interest over time as reality diverges from our assumptions. The real art isn't writing perfect code, but understanding which technical debts are worth taking on.
The reason why we build software is so that customers will use it to do the things they want to do. That’s the only sensible frame for deciding when and how much technical debt to incur.
Good luck. Happy borrowing.
Bursting with stories from Rowan's first hand experiences
Most startup advice is dangerously wrong. The mythology of the lone genius founder, the obsession with capital raising and the theatre of startup ecosystems lead countless ventures astray.
Drawing on two decades at the heart of New Zealand's most successful technology companies – Trade Me, Xero, Vend and Timely – this new book unravels the messy reality behind familiar glossy success stories. Combining raw honesty and sharp analysis, it challenges conventional wisdom by sharing compelling firsthand lessons about focused execution, team building and genuine ecosystem growth.
This myth-busting guide is essential reading for founders, investors and policymakers alike, demonstrating that embracing uncertainty, recognising patterns and learning quickly from mistakes are not just steps on the path to success – they are the path itself.
Sometimes the only way to be right is to get comfortable with being wrong.
Pre-sales are available now at https://shop.howtobewrongbook.com.
If you’d like to take a look inside first, you can also download the first chapter for free.
If you prefer you can also buy from BookHero.co.nz. This is a new an independent online bookstore, based in Auckland, which prides itself on customer service, and fast delivery (overnight where possible). I’m delighted they have decided to stock How To Be Wrong, along with 10,000 other titles. Check them out.
How To Be Wrong is proudly published by:
Photo by Gayatri Malhotra on Unsplash
Ctrl-Z merchandise is also sold separately - for those hanging out for the ebook or audiobook versions.
For a detailed description of why this is true and an alternative approach to solving this problem I recommend the seminal essay by Joel Spolsky called Things You Should Never Do, Part I, published in April 2000. In How To Be Wrong I describe how we applied those ideas to re-write Trade Me in .NET starting in 2005.