Built for your Tuesday morning

A Tuesday morning

There's a particular kind of morning that anyone who's run a real operation will recognise.

You open your phone at 7:30. There are 47 emails from customers waiting. Three are angry. One is from your biggest account — the one you spent a year winning — asking why their order didn't arrive yesterday. There's an email from a supplier saying the part you'd promised would land Friday is now delayed two weeks. Your warehouse manager has WhatsApped you a photo of an empty shelf that should be full. Your sales director rang twice last night and you forgot to call back. You haven't had coffee yet.

This is what running a business actually feels like, on a more-than-occasional Tuesday. And it's a thing that almost no developer in your software vendor's office has ever lived through.

That gap is the most important thing to understand about who's building your software.

What they don't know they don't know

Most developers — including most of the talented ones, including the ones who genuinely care — have only ever worked in tech. University, internship, agency, in-house team. They've never:

• Woken up to fifty customer-services emails before their second coffee
• Had the email from a supplier saying "sorry, that delivery you were counting on is delayed two weeks", and had to work out which fifteen customers to ring before lunch
• Sat with a finance director on the last day of the month and watched the cash position tighten by the hour
• Had a year-end where the system can't produce the report the accountant needs, and the only solution is somebody manually re-keying eight thousand transactions
• Promised a customer something on Friday and let them down on Monday because something a layer below them was breaking quietly the whole time
• Stood in front of dozens of unhappy customers — by phone, by email, in the showroom — and absorbed the consequences of a system that didn't quite do what it said it did

These are the moments software is supposed to be there for. They're the entire point of building business software at all. They're also the moments developers who've never lived through them tend to discount, because they're not what gets talked about at conferences.

What this means when they build software for you

Without that visceral context, the wrong things get optimised.

Decisions get made on what's interesting — the new framework, the architectural pattern someone wrote a Medium post about, the cloud service that just hit beta. They get made on what's new, because new is exciting. They get made on what's trendy, because that's what the developer's peers will respect.

What they don't get made on, often enough, is what's dependable on a Tuesday morning when you've got 47 emails waiting and your warehouse manager is staring at an empty shelf.

The honest version: an awful lot of business software fails not because it was badly built, but because it was built to be impressive instead of built to be there. Impressive software is the demo. There software is the thing nobody mentions, because they don't have to.

What good actually looks like

Good business software is software you stop noticing.

It runs the overnight job that reconciles the bank feed at 2am and you don't think about it. It generates the invoices and they're right. It shows the warehouse manager today's pick list and the list is in picking order. It draws the chart on the finance director's screen at 8:30 and the chart matches reality. None of it is impressive. It's just there.

This is unsexy work. It's the kind of work nobody writes a conference talk about. It's the kind of work that doesn't win awards, doesn't trend on Hacker News, and doesn't end up on a developer's CV-of-impressive-things.

It's also the only kind of software that earns its keep in a real business.

The mission is not to write interesting code. The mission is to make something practical, dependable, and beneficial to the business that's paying for it.

The kind of decisions this leads to

If you've sat in the chair where the consequences of bad software actually land, you make different choices about how to build it.

You pick the boring database that's been around for thirty years over the trendy one that's six months old. You write the dull background job that retries when the courier API is having a bad afternoon. You spend an hour adding the audit log that nobody'll ever look at, until the day they really need it. You build the export the bookkeeper asked for in the format she actually uses, even though it's CSV and CSV isn't fashionable.

You also stop being precious about your own code. The developer who's never had your Tuesday morning is the one who'll fight to keep the elegant abstraction. The developer who has is the one who'll happily replace it with three lines of boring, obvious procedural code — because that's the version that'll still make sense at 3am when somebody has to fix it.

What we actually do differently

We're not going to claim every developer needs to have spent a decade on a warehouse floor before they're allowed to write code. That would be silly, and it isn't true.

But the operational reality of the businesses we work with is something we make sure we put ourselves in front of — and we don't write a line of code without it.

That looks like:

• Spending the first days of a project sitting next to the team whose work the software is going to change. Not interviewing them in a conference room. Watching the actual job happen.
• Asking what goes wrong on a bad Tuesday, not just what the process is on a good one. The bad days are where software earns its keep.
• Doing the boring discovery work — measuring where time actually goes, where errors actually land, what the workaround tax actually is — before getting near a screen.
• Building the dependable, unfashionable thing first. Trendy adornments later, only if they earn their place.
• Being the same person you talk to in three years' time. Most of our clients are still working with the same senior dev who built the original system. There's no inheritance problem, because nothing got inherited.

It also looks like turning up to meetings as the kind of person you'd be comfortable putting in front of your finance director. Not because of what we're wearing, but because we'll spend the meeting talking about your business — your customers, your suppliers, your bad Tuesdays, your year-end — and not about which JavaScript framework we used last sprint.

The conversations that matter happen one-on-one

The first of those bullets does the most work, and it deserves more than a bullet.

The deepest knowledge in any operation is rarely held by the loudest people in the meeting. It's held by the warehouse supervisor who's been doing the picking route for fourteen years. The bookkeeper who knows why the spreadsheet has a hidden column called "Sarah's adjustments". The customer-services lead who knows which three customers always need to be rung the day before delivery, even though there's no flag on their account.

These people almost never volunteer this knowledge in a room of twelve. Hierarchy gets in the way. So does politeness. So does "this is just how I do my job, who'd want to hear about it?" They sit through the discovery workshop, nod in the right places, and the most useful sentences they could give you stay unsaid.

So we get them on their own. At their desk, on the warehouse floor, sat in the office kitchen at 11am with two mugs of tea. Not in a meeting room with three of their managers in. We don't open a laptop. We don't ask them what their requirements are. We ask them to walk us through what they did this morning.

It takes time. You rarely get the real answers in the first half hour, and often not in the first session. People need to be sure you're not there to make their job sound stupid in front of their boss. They need to be sure you're actually listening. They need to be sure they won't get into trouble for what they're about to tell you.

But almost without exception, somewhere in the second or third visit, the moment lands. They'll be halfway through explaining how they batch up the orders before they put them into the system, and they'll pause, and they'll say:

"This is a bit nuts, I know, but..."

That sentence is the whole reason we do this. Because the thing they're about to describe is almost always:

• The biggest hidden cost in the workflow
• A workaround they invented to compensate for software that doesn't do what they need
• Something nobody upstairs even knows happens
• Fixable with the right small piece of software

Until they said it out loud to somebody patient enough to listen, they hadn't even registered it as a problem. It was just the way the job gets done.

That's the real reason we sit next to a team. Not for the requirements list — anybody can write a requirements list. For the unsaid bits. The bits the person didn't know they knew.

The mission

This is the part that gets lost in the developer's enthusiasm for their craft.

The mission is not to write interesting code. The mission is not to use the new tools. The mission is not to win the architectural argument with the developer at the next desk.

The mission is to make something practical, dependable, and beneficial to the business that's paying for it. Something that's there on a Tuesday morning when you've got 47 emails waiting and you need it to just work.

It isn't sexy. It's boring, and it just works.

That's the entire job.

If that's the kind of software vendor you've been quietly looking for, say hello.