Before that, building a graphical application for Windows meant managing an event loop in code – a constant cycle in which your program checked what was happening in the operating system, decided which events it cared about, handled them, asked for a screen redraw, did the redrawing, and carefully released enough processing resources to let other programs continue running. To say it was complex is an understatement. Iterative interface design – trying something, seeing how it felt, adjusting – was genuinely difficult. VB changed all of that. It made GUI development accessible in a way that nothing had before.

I evangelised it to every developer I knew. Most of them couldn’t see it yet. They came around.

But it wasn’t all good. VB’s accessibility attracted less expert programmers and non-programmers who had dabbled in Basic on a home PC. Much of what followed was a mess. Business logic became deeply entangled with visual components. Software was shipped without adequate testing – automated testing of GUI applications was poorly understood, and the people building in VB often weren’t experienced enough to know what they didn’t know. An old industry adage proved itself, repeatedly: you can write COBOL in any language. The tool changes. The thinking required to use it well does not.

I have been watching the current conversation about AI and software development with a strong sense of familiarity.

The phenomenon has acquired a name vibe coding – which captures it well: using an AI assistant to generate code through conversation, iterating on the output, shipping the result. The parallels with the VB moment are not subtle. A technology arrives that makes programming accessible to people who couldn’t previously do it, and dramatically accelerates the work of people who could. The coverage is enthusiastic. The evangelists are out in force. The consequences that nobody is quite ready to discuss are already accumulating.

Let me be honest about both sides.

What genuinely changes is real. The speed at which an experienced developer can implement well-understood functionality has increased substantially. Boilerplate, routine integrations, the first draft of a feature – AI handles these faster than any human. For personal projects and small-scale tools, vibe coding works: if something goes wrong, the person who built it is close enough to notice and fix it. The barrier to building software has lowered again, and some of what gets built at that lower barrier is genuinely useful.

What doesn’t change is more important.

The else clause doesn’t care how the code was generated. I wrote recently about the moment a developer implementing a payment feature types the word “else” and stops – confronted by the cascade of questions that only become visible at the point of implementation. What happens when the payment gateway times out? When the card is declined for one of several distinct reasons? When the payment succeeds but the confirmation email fails? None of those questions are in the AI prompt. They are only visible from close range, and answering them requires judgment that the AI does not have and the vibe coder may not have either. For a personal project, an unhandled edge case is an inconvenience. For a system handling real transactions for real customers, it is something else entirely.

The belief that design is now optional is gaining traction in places that should know better. The idea that you can describe what you want in conversation with an AI and deploy the result – without thinking through requirements, failure modes, or any of the work that precedes responsible implementation – does not work for software of any significance. The AI will generate something. It will often look plausible. What it will not do is tell you what you forgot to ask for.

The consequences for professional developers are serious and largely absent from the coverage. Senior developers – whose job has always included reviewing and correcting the work of more junior colleagues – are now contending with code being generated at a pace no review process was designed to handle. The volume is extraordinary. The quality varies enormously. Seniors are increasingly seen as the bottleneck in the “construction” of software, are being pushed to review faster, and are burning out. This is not a hypothetical. It is happening now, in organisations that have adopted AI coding tools without thinking through what happens to the humans in the loop.

And then there is the question I find most troubling.

Junior developers learn to become senior developers by encountering problems. The obtuse error message that takes two days to diagnose and turns out to be a network configuration issue on one specific server. The unexpected interaction between two libraries that produces behaviour nobody anticipated. The edge case that only surfaces under load, at 2am, in production. These encounters are not inefficiencies to be optimised away. They are the education. A junior developer who generates code through an AI assistant and ships it without deeply understanding what it does is not building the judgment that the industry will need from them in ten years.

So. What changes?

The speed at which you can build the wrong thing increases dramatically. The thinking required to build the right thing does not. And the people the industry will need to do that thinking – experienced enough to know what questions the AI isn’t asking – are burning out at the senior end and failing to develop at the junior end.

Nobody seems to be treating that as the emergency it is.

My parents didn’t bring a life with them from Greece. They met in the suburbs of 1950s Melbourne and decided to build one from scratch. My father was a man of the factory floor; my mother, a woman of the needle and thread. They had arrived in Australia separately, with nothing but the kind of stubborn resilience that a village upbringing in Greece either forges or breaks. When they finally scraped together enough to buy their first home in Bank St, South Melbourne — then a low-price, worker’s suburb, not the trendy, up-market suburb it is today — they didn’t celebrate by spreading out. They celebrated by squeezing in.

I spent my childhood in a house where my parents, my sister, and I shared a single bedroom, while the rest of the house was a revolving door of new arrivals – young men, women, and families who had stepped off a boat with a cardboard suitcase and a look of profound displacement. Rent wasn’t a monthly transaction. You didn’t pay a cent until you found a job, and you didn’t leave until you’d saved enough to buy a front door of your own.

The air in our shared kitchen was thick with roasted lamb, Greek tobacco, and the collective anxiety of people trying to learn a new syntax for home. By modern council codes, the arrangements would probably be condemned. In practice, it was the most efficient social safety net ever designed. My parents understood something my generation has largely forgotten: a house isn’t a private sanctuary or a diversified asset. It’s a lifeboat. And in a lifeboat, you don’t complain about the lack of legroom. You keep pulling people out of the water.

The rhythm of that house was the hum of my mother’s sewing machine. My father’s hands were stained with factory grease; my mother’s back was permanently shaped by hours bent over her work. They were workers in the most literal sense – trading their physical stamina for a foothold in a country that didn’t always know what to do with them. But their labour didn’t end when they clocked off. The second shift began at the kitchen table.

This was where the unwritten contract of the Greek community was signed. They helped the newcomers navigate the terrifying bureaucracy of a new country, translated documents they barely understood themselves, walked people into the factory and vouched for them by name. They weren’t just providing a bed. They were providing a bridge.

Some of those strangers who occupied the back rooms of our house never really left our lives. They became the fabric of our family – there for the christenings, the funerals, and dancing the most enthusiastically at my wedding. The guest list that day wasn’t just a collection of relatives. It was a map of my parents’ generosity. Several of the people there had spent their first night in Australia on a makeshift bed in our dining room.

My parents didn’t have degrees in sociology. But they understood what I think of as ancestral mathematics: you don’t subtract from your life by adding someone else to your dinner table. You multiply your security. True resilience is communal. If the factory closed or the sewing commissions dried up, their house wouldn’t fall – because it was held up by the dozens of people they had once sheltered.

I look at the way we live now – the clean, quiet streets, the high fences, the video doorbell that lets me check whether I can afford to ignore whoever is knocking – and I see clearly what we bought with our success.

We bought silence.

We’ve outsourced our safety nets to insurance companies and superannuation funds. We have apps for delivery so we don’t have to talk to shopkeepers. We’ve learned to call “not wanting to help” by the more comfortable name of “setting boundaries.” We treat the house as a box that accrues value while we sit inside it, scrolling. My parents treated it as a machine for producing successful citizens.

I’m not suggesting we go back to four families sharing one bathroom. We’ve earned our bedrooms and our privacy, and I for one intend to keep them. But I think we need to remember the spirit of that shared kitchen. The most valuable thing you can do with a spare room – whether it’s physical, financial, or simply a pocket of time you’ve kept for yourself – is to put someone in it until they can stand on their own two feet.

My parents arrived with nothing. They left a legacy of full rooms.

I hope my generation doesn’t end up with everything, only to realise we’re the only ones in the house.

Everyone in the room has seen this chart before. The developers have seen it many times. They are looking at it now with the particular expression of people who have learned, through painful experience, that pointing out the obvious is rarely worth the political capital it costs.

The chart is fiction. Everyone in the room knows it is fiction. The meeting will proceed as though it is not.

This scene plays out, with only minor variations, in organisations everywhere, every day. I have been in that room more times than I care to count, on both sides of the table. After forty-five years in the industry, I have come to believe that the thinking buried inside that chart — a mental model so pervasive that most people have never stopped to question it — is responsible for more wasted money, more broken working relationships, and more sheer human misery than any other single factor in the history of software development.

That is a large claim. Let me make the case for it.

The mental model goes like this: software development is fundamentally similar to building construction. You gather your requirements — the architect’s drawings — produce a detailed design, and then hand it to a team of developers who build the thing according to the plan. The building part is where the time and money go. The rest is just planning.

This feels intuitive. It satisfies the finance department’s need for a budget. It gives management something to approve and something to hold people accountable to. It maps neatly onto every other capital project an organisation might undertake. And it is wrong. Not approximately wrong, not wrong in ways that better tools might correct. Fundamentally, structurally wrong — because software development is not construction. It is design, all the way down, and design does not work the way construction does.

In construction, an architect can specify a building in sufficient detail that a crew can build it without constantly referring back for decisions. The materials behave predictably. The edge cases have been resolved by generations of previous builders. None of this is true in software. The domain is almost always novel — if it weren’t, you’d buy existing software rather than building new software. The technologies change constantly. And the edge cases cannot be fully enumerated by anyone sitting in a room writing a requirements document. They can only be discovered by building the system and watching what happens.

Consider a developer implementing an online payment feature. The requirements describe the happy path clearly: the user enters their card details, the payment is processed, the order is confirmed. Straightforward. Then the developer types the word “else” — the part of the code that handles what happens when things don’t go as expected — and stops.

Is a payment gateway timeout the same as a declined card? Should the system retry, and how many times? Is an expired card the same message as a stolen card? If the payment succeeds but the confirmation email fails, has the order been placed? If the user tries again, will they be charged twice? None of these questions are in the requirements document. They couldn’t be — they only become visible from the point in the implementation where you are close enough to the actual behaviour of the system to see them. The requirements described what the feature should do when it works. They said almost nothing about what it should do when it doesn’t, because you can only enumerate those cases by building the thing. This is not a planning failure. It is the normal, expected, entirely routine operation of software development. Every significant feature has its else clause. The Gantt chart has no column for it.

The software industry tried to solve this, twice. The first attempt was the waterfall methodology — named for its diagram showing project phases flowing downward in sequence, each completing before the next begins — which crystallised through the 1970s as the discipline’s answer to the chaos of early software projects. It looked like engineering. It produced documents management could review and approve. It gave finance a basis for budgeting. And it failed, consistently and expensively, for exactly the reasons described above: it was built on the assumption that you could know everything that mattered before you started building, which you cannot.

By the late 1990s there was enough wreckage from waterfall projects to generate serious dissatisfaction. Out of that came the Agile Manifesto of 2001 — a short document signed by seventeen developers who had gathered to articulate what a better approach might look like. It is worth reading if you haven’t. It values individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. Not one of those values mentions two-week sprints, or daily standups, or story points, or velocity charts.

What most organisations adopted in the name of agile was a project management framework. Which is a different thing entirely. A sprint is just a short waterfall. A backlog is just a requirements document broken into smaller pieces. If the underlying assumption is still that software can be planned, estimated, and tracked like a construction project, changing the vocabulary and the cadence changes nothing fundamental. What you get instead is what practitioners have taken to calling “agile theatre”: the team holds its standups, the Scrum Master facilitates the retrospective, and meanwhile, somewhere above all of this, a senior manager has a spreadsheet with a delivery date committed to before the first sprint began, derived from an estimate produced before anyone wrote a line of code. The ceremonies continue. The date does not move.

I have written elsewhere about what happens when someone gives an honest estimate in this environment. It tends not to go well for them.

So why does the fiction persist? Because it is useful. Not useful for building good software — fifty years of evidence is unambiguous on that. Useful for conducting business in a way that feels manageable to everyone involved.

Consider the position of a large consulting firm bidding for a software contract. The client wants a fixed price and a guaranteed delivery date. The honest response — that both are unavailable at this stage, because the full scope of what will be required cannot be known until a substantial portion of the work is done — tends not to win contracts. The response that wins is a confident number and a confident date, underwritten by a methodology impressive enough to make both look credible. The firm that gives the honest answer loses the work. The firm that gives the confident answer wins it, and then has years of billing ahead regardless of whether the project succeeds, because extracting a large consulting organisation from an in-progress project is itself a significant undertaking. This is not a description of dishonest behaviour. It is a description of incentives that systematically reward the perpetuation of a false mental model.

The cost of those incentives is not abstract. I worked with a developer early in my career — talented, conscientious, someone who genuinely cared about the quality of what she built — who spent eighteen months on a government project contracted on a fixed-price, fixed-scope basis, with a scope that had been defined before anyone wrote a line of code. By month twelve she was working weekends routinely. By month eighteen the system had been delivered — late, incomplete in the ways that the contract did not technically require to be complete — and she left the industry shortly afterward. She had been in it for four years.

I have seen versions of that story more times than I care to count. The details change. The structure doesn’t. A commitment is made before the necessary information exists to make it responsibly. Everyone downstream absorbs the consequences.

The Gantt chart on the screen is not the problem. It is a symptom. The problem is a fifty-year-old mental model that the people funding software projects find too useful to give up, and that the people building software projects have learned it is not worth their careers to challenge.

That is not where you want to be. And it is exactly where most organisations are.

My book, Code Is Design, goes into this topic in a way that is accessible to both the technical people and those that are managing or underwriting software development projects.
It is available now on Amazon.

Let me back up.

My GP had been my doctor since I was a teenager — a little older than me, someone I thought of, and still think of, as a friend who happens to have a medical degree. After years of watching my weight trend upward through the fluctuations, he sat me down for a conversation of a different kind. Not the usual review of blood tests and medication adjustments. A proper one.

He said he understood that losing weight was hard. That the conventional advice — eat less, move more — was a gross oversimplification that failed to account for the reality of what my body was actually doing. He was not there to make me feel worse about what I had tried and not achieved. But he was also not going to let me leave without being clear about what the numbers were telling him. At 158 kilograms, carrying the metabolic load of advanced Type 2 diabetes, my life expectancy was, in his professional judgement, severely compromised.

Not a lecture. A fact, delivered with the directness of someone who cares enough about you to say the hard thing.

I asked him what else there was. He thought for a moment, then told me about a procedure beginning to produce notable results — new enough that he wanted to refer me to the leading practitioner rather than attempt to summarise it himself. The procedure he was talking about was laparoscopic adjustable gastric banding, or what is now commonly referred to as a lap band.

My wife and I did our research. We attended presentations. We spoke with people who had already had the procedure — early recipients, willing to answer questions from strangers about something deeply personal. The picture that emerged was honest about the trade-offs. Certain foods would cause problems. Meals out would carry a background level of anxiety, indefinitely. The band could not stop liquid calories, so the discipline still had to be there. It was a structural constraint, not a substitute for judgement.

None of this was disqualifying. But it required honest consideration, and we gave it that. Several months of it. Weighing the risks against the alternative. Sitting with the question of whether this was the right thing to do.

In the end, we decided to go ahead.

I remember lying on the hospital bed in the pre-surgery bay, in the standard-issue gown that hospital gowns have apparently been since the beginning of time, waiting to be taken through to theatre. Two orderlies arrived with a narrower wheeled trolley — the kind used to transfer patients into the operating room. One of them asked me to slide across.

The other stopped him, took him a few steps away, and said, in the tone of someone who doesn’t think they’re being overheard: patients over 150 kilograms cannot be transferred on the trolley.

I heard it. He didn’t intend me to, and there was nothing malicious in it — just a practical observation between two people doing their jobs. But I heard it.

They wheeled the hospital bed itself into the theatre instead.

I have thought about that moment many times in the years since. At the time it hit me with a force I hadn’t expected — a sudden, stark encounter with what I had become, delivered without commentary or judgement, which somehow made it worse. I made a decision in that moment, lying on that bed being wheeled through the corridor: I was going to do whatever it took. Whatever discomfort, whatever inconvenience, whatever the procedure demanded. I was going to get my weight under control. That was not negotiable any more.

That was probably the real turning point. Not the surgery. The moment before it.

The years that followed involved karate — which deserves its own post, and will get one — and a weight loss, over time, of around 60 kilograms. My insulin requirements dropped, then disappeared. The other medications followed. For six years I managed Type 2 diabetes on no medication at all. The disease is progressive, and it came back. But those six years happened, and they happened because of a decision made in a hospital corridor that nobody planned and nobody witnessed.

Here is what I want to say about that. We talk about decisions to change as though they are acts of will — as though the problem is simply that people haven’t decided hard enough yet. That has not been my experience. What actually moved me was not discipline. It was a moment of clarity, arrived at sideways, in a context I couldn’t have predicted. The orderly wasn’t trying to help me. He didn’t know he did.

And the other thing: at no point in this story did the answer turn out to be trying harder at what hadn’t worked. It turned out to be a medical intervention. Obesity is a disease. It responds to medical treatment. The fact that we spent decades treating it as a character flaw has cost a great deal — in suffering, in shortened lives, in patients told to try harder at things that were never going to be sufficient.

I was one of those patients. For a long time.

Next week, Ground Truth moves on to another topic. If you are interested in reading more about my story dealing with diabetes, my book “The Long Road Down” is a first-hand account of what 30 years living with Type 2 diabetes is like. It is available now on Amazon.

I write about my own experience managing Type 2 diabetes — thirty-plus years of it. None of this is medical advice. Your situation is not my situation, and nothing here should be a reason to change your treatment without talking to your doctor first.

Let me back up.

I was diagnosed with Type 2 diabetes in 1994, aged thirty-five. The diagnosis arrived at the end of a day when I had fallen asleep on the office sofa and woken six hours later to my wife’s increasingly non-negotiable phone calls. I went from the GP’s surgery directly to hospital. That was the beginning of a management relationship with the disease that has now lasted more than thirty years — through insulin injections, through a lap band procedure, through karate, through six years off all medication, followed by the slow, humbling return of the disease in its progressive form. I know this disease. I know its rhythms, its responses, its particular habit of ignoring things you try on it.

Three years ago, my endocrinologist added Ozempic to my regimen. Not for weight loss. For blood glucose management. It works on a hormone pathway that stimulates insulin production in response to meals, among other things, and for someone managing advanced, long-standing Type 2 diabetes, it is genuinely effective for that purpose. That is why I am on it. Weight loss was never the goal.

Good. Now let me tell you what the coverage doesn’t.

Ozempic has side effects. The medical literature acknowledges this in careful, measured language — “gastrointestinal effects,” “abdominal discomfort” — as though it were describing mild inconveniences. What the literature does not convey, and what no celebrity profile of the drug has mentioned, is the particular social texture of those effects. The flatulence is persistent, loud, and largely indifferent to social context. The belching is similarly uninvited. The stomach noises — a deep, rolling interior gurgling — have announced themselves in meetings. They have interrupted conversations. They have no sense of occasion whatsoever.

I say this not to be indelicate but because people deserve accurate information before they start. I have had to become strategic about positioning in rooms. That is a sentence I never expected to write.

There is also fatigue, particularly in the days immediately after injection. Not incapacitating, but present — a heaviness I have learned to plan around. And injection site reactions: the occasional lump, the lingering tenderness. For someone who already administers a nightly insulin injection, a weekly subcutaneous shot is not an unfamiliar experience — but it adds to the accounting. This is the pharmacological management of a chronic disease. It is not glamorous. Nobody is writing long profiles of what that part feels like.

Now. The weight.

Over three years on Ozempic, I have lost approximately five kilograms. I am not entirely convinced the drug deserves credit for all of it. Here is why. My wife and I spend three months of every year in Greece. In Greece, I reliably lose around two kilograms — better food, more walking, lower stress, Mediterranean everything. In Australia, on the same drug, same dose, same treatment regimen, I do not lose weight. Or not anything measurable beyond ordinary fluctuation.

My endocrinologist has views about this — olive oil and insulin sensitivity feature prominently — and I find the explanations plausible. But I cannot fully explain it, and I am wary of anyone who claims they can. What I know is that the drug the headlines have called transformative has, in my experience, not produced the transformation the headlines describe. It is doing something useful. Weight loss is not the primary thing it is doing.

Perhaps the pharmaceutical companies should stop trying to synthesise the molecule and start trying to synthesise a month in a Greek village. It is, in my experience, the only thing that actually moves the needle for me.

Now. The supply shortage.

For roughly two years — and the memory is still fresh enough to sting — obtaining Ozempic required persistence. Multiple calls to multiple pharmacies. Occasional failure. Occasional expensive workarounds. The supply had been overwhelmed by off-label demand: people without diabetes, prescribed it for weight loss.

I want to be careful here, because I believe obesity is a real disease. Not a character flaw, not a failure of willpower, not something that better choices would simply fix. A genuine medical condition with complex metabolic, genetic, and environmental drivers, and one that deserves to be treated with the same seriousness we extend to any other chronic illness. That is not a pro forma disclaimer. I mean it.

But there is a prioritisation question that nobody seemed particularly interested in asking. When patients using a drug for glycaemic control — patients for whom it is not a lifestyle intervention but a component of managing a serious, progressive condition — cannot reliably obtain it, something has gone wrong with how we’ve allocated access. The market found its equilibrium eventually. The supply situation has largely resolved. But the conversation about who bore the cost during those two years, and whether that was acceptable, has never really happened.

That is the story you do not read. Not because it is hidden. Because the people writing about Ozempic are not the people who were on it before it became famous, and the patients for whom it is simply the latest chapter in a very long story have not been given much column space.

I keep reading the coverage looking for something that resembles my experience. I am still looking.

I write about my own experience managing Type 2 diabetes — thirty-plus years of it. None of this is medical advice. Your situation is not my situation, and nothing here should be a reason to change your treatment without talking to your doctor first.

We were a small software house — I was CTO — and we had built something worth having: a finance origination platform that we white-labelled and customised for clients in a specialised industry. Each implementation meant taking the core system and shaping it around how a particular client operated: their product structures, their incentive arrangements, their promotions, all layered on top of the financial and accounting requirements that the law doesn’t negotiate on. We were good at it. We were building a reputation. And one of the largest players in the industry took notice.

They sent us an RFP. Attached to it was a requirement that we found rather more interesting than the specifications: the work had to be complete within six months of engagement.

This was a David and Goliath situation — they were that much larger than we were — and our CEO very much wanted to land them. I very much did not want to respond at all. The requirements document was a mixed bag of incompatible specifications, and when we asked questions, the answers were uninformative and faintly annoyed, as though the questions themselves were an impertinence.

We responded anyway. Our honest estimate broke into two phases: two months of white-labelling running concurrently with one month of requirements clarification, followed by a second engagement for the remaining customisation work — somewhere between six and ten months, depending on how the conflicting requirements resolved and how complex the integration with their general ledger system turned out to be. Eight to twelve elapsed months in total. We couldn’t be more specific than that. Nobody could, honestly, at that stage.

In the process of preparing the bid, I had got to know one of their staff. We weren’t friends — more like two people who had recognised something in each other across a table. We both understood what was actually happening: that any estimate submitted in response to this RFP was a guess at best and pure fiction at worst. He knew it. I knew it. The difference was that I was writing mine down honestly.

At our end-of-year company picnic, the CEO told me we hadn’t got it. I stepped aside and called my contact at the other firm. He let slip — probably more than he should have — that we’d been rejected because we couldn’t commit to six months. The successful applicant, a large offshore consulting firm, had committed to the timeline and come in at roughly the same price.

Our CEO was crestfallen. Our development team, when I told them, reacted the way I had: with quiet, private relief. There is something clarifying about losing work you didn’t want.

Three years or so later, I ran into that same contact at a conference. About agile development, as it happens. He had moved on to another company but was still in touch with people at his old firm. Over a beer — low-carbohydrate, given my circumstances — he told me what had happened. The project had run for a little over two years. It had cost approximately three times what we had proposed. It had been scrapped. They were going out for new proposals.

Were we invited to respond this time?

We were not. Either they were too embarrassed — unlikely — or they were still looking for someone to tell them what they wanted to hear.

I hope they found them.

This story is one instance of a general pattern — an industry built on a mental model that everyone in the room knows is wrong. I’ve made the full case in Code is Design. It turned out to need a book rather than an essay.

These are posts about places: a particular stretch of road in the Peloponnese where history turned on a single morning, or the quarter of Athens where refugees from Smyrna settled after 1922 and changed Greek music forever. History, culture, the meaning that accumulates in places over centuries. The kind of thing that takes a while to explain properly.

That instinct — to not stop before the idea is actually clear — has been with me since the beginning.

In the late 1970s, I was so shy that having to address five people in a room would cause me to break out in a cold sweat. I’d start a sentence and lose the thread before I’d finished it. Clearly, this was not going to work. So I did something deliberate: I volunteered to teach the introductory sessions of the commercial programming course I had just completed. Evening classes, four weeks. I knew the material cold, which meant I could use the energy I would otherwise have spent on panic to work on exactly one thing: learning how to talk to a room.

It worked. Within a few years I was presenting at major conferences. When Microsoft launched VB5, they sent me around Australia to present to audiences of thousands. When Borland released Delphi, I did the same across Australia and New Zealand. I wrote a monthly column for a technical publication. A major publisher approached me about writing a book — and I didn’t pursue it, for reasons that made sense at the time. I’ve spent the years since regretting it.

Last month, I finally wrote the book. *Code Is Design* is about why software projects fail — which turns out to be about a fundamental misunderstanding of what software development actually is. Writing it confirmed something I already knew: I still have things to say, and I’m still not finished saying them.

So. Ground Truth.

The name means what it says. We are living through a period in which facts are being systematically contested, weaponised, and replaced with narratives designed to divide. I am watching the contempt for expertise — the manufactured grievance, the tribal loyalty test, the aggressive denial of observable reality — emerge in Australian public life in ways that would have seemed extraordinary ten years ago. I have children who are working harder than my wife and I ever had to, for less security. I have grandchildren who will inherit whatever world we leave for them.

I am not a political commentator and I have no interest in becoming one. But I’ve spent forty-five years in an industry that runs on whether you’re willing to tell people what you actually think rather than what they want to hear — and I’ve come to believe that clear, honest explanation from someone who has actually done something is in shorter supply than it should be.

Ground Truth will cover technology and organisations, because that’s where I’ve spent most of my working life. It will cover health, because thirty years of managing Type 2 diabetes has given me a perspective I didn’t ask for and won’t waste. It will cover Greek-Australian life, history, and identity, because that’s where I come from and it is underwritten in the broader culture in ways that deserve more attention than they get. And it will cover whatever else demands attention.

One post a week. Honest, I hope. Occasionally long.

My wife has been warned.