Nobody Wants a Better Printer, and It Made Me Rewrite

DHH went on David Senra's show for a hundred minutes. Almost none of it was about code. It was about how to keep a company profitable without handing over control of it.

One line in the middle of it made me open my own planning documents and change them.

He was talking about his laser printer. He remembers the model number, a Brother HL2340WD. He said if Brother released a better one tomorrow, he would have no interest at all. He is not in the market for a better product. He is in the market for the product he already bought.

What he wants is for that printer to still be there next year, with the button in the same place and a driver that still installs.

They actually live by it

This is not a rhetorical position for 37signals. The first version of Basecamp, from 2004, stopped being sold in 2010 and is still running today. It still brings in millions a year, and almost all of it is profit. Basecamp 2 is still running. Highrise, a CRM they built years ago, is frozen and no longer developed, and still does millions in business.

The promise they give customers is that these things will stay up until the end of the internet.

When Basecamp 5 shipped, one category of complaint he got was, in his words, why did you mess with my printer, that button used to be on the right.

He said he envies physical and cultural products. A book gets published and it is published. A film gets released and it is released. They get to be finished. Software never gets to be finished, and every change it receives is, for the people already using it, mostly a cost.

Why this lands hard in a hospital

I am the head of information technology at a regional hospital in Taiwan. Hardware architecture, system design, how those systems run day to day, whether we adopt something new at all, those decisions land on my desk. One of the systems I am responsible for is a hospital information system that has been running for more than twenty years.

Some of its screens are genuinely ugly. The nurses can operate them with their eyes closed.

Every time someone suggests that we should tidy up the interface while we are in there, my first reaction used to be enthusiasm. Now my first question is different. Who is being charged the cost of relearning this, and can they afford it?

There is a bigger reversal underneath that. I had been treating the fact that the old system is still alive as a form of unfinished business. A debt. After this interview I think it can also be the shape of a promise that is being kept.

What I changed in my own plan

I have a written proposal for migrating that twenty year old system to SMART on FHIR using the strangler fig pattern. Wrap the legacy system in a standards based facade, grow all new functionality on the new side, and let the standard interfaces take over the old responsibilities one at a time.

Two things in that document were wrong, and the printer line is what showed me.

One. The goal was decommissioning, and that was the wrong success metric.

My final phase measured progress by how few legacy tables were still being read, working toward the day the old system could be switched off. But being switched off has no value to any user. It only has value to me, because it shrinks my maintenance surface. Nobody at the nurses' station is waiting for the old system to die. They are waiting for that screen to still be in the same place next year.

Two. I had written that indefinite coexistence is unacceptable, and that was too blunt.

It welded together two different things. Here is the split I should have made:

What cannot coexist indefinitely is data ownership. One piece of data with two systems of record, both writable, is the kind of coexistence that eventually hurts a patient. That has to converge, and it has to converge to a named side.

What can coexist indefinitely is the user interface. An old screen that has been demoted to read only, reading from a single system of record, causes no inconsistency at all. Its cost of existing is mine. Its cost of disappearing is the user's.

My mistake was applying the standard I needed for data ownership to the interface as well.

So the final phase now has three dispositions instead of one destination:

Take over. Data ownership moves to the FHIR side, the old screen stays and becomes read only. Zero change for the user, fully strangled from the system's point of view. This is where most modules should end.
Freeze. The module stops being developed but keeps serving, with no sunset date. This is for the parts that people still press every day and that have no new requirements. Freezing is not failure. Freezing is what a kept promise looks like.
Decommission. Only when there are genuinely no users left, or the legal retention period has passed. Having a newer version is not a reason to switch something off.

I also added a rule that applies to every phase, and a metric that points the other way.

The rule is that before any change, I have to work out who is being charged the cost of relearning. If they cannot afford it, the change does not happen. Tidying up an interface along the way is not a bonus in this plan. It is me spending someone else's time to make my architecture feel cleaner.

The metric is the number of clinical staff who have had to relearn how to do their job because of this migration. My old progress measures, how many legacy tables remain and how many lines are left in the translation layer, only see my side of the wall. The target for the new one is zero, not few.

And one honest note about the cost, because this doctrine is not free. Frozen modules keep absorbing security patches and dependency rot. DHH has an entire company to keep old versions alive. I have me. So a module only earns the right to be frozen once it has completed step one and is read only. Freezing something that still writes is not freezing. That is just running two systems at once.

Four other things worth your time

Constraints were the design tool, and we just lost them. The first version of Basecamp was built in 380 hours, ten hours a week, while he was a fifteen dollar an hour contractor. Then he said the line I wrote down first: if you have 380 hours and ten agents, you can build a monstrosity. Basecamp 5 was their first AI accelerated release and they had to kill finished features right at the point of shipping, because he does not trust himself to show restraint when everything he wants is cheap. For fifteen years, not being able to finish things quietly blocked a lot of bad ideas. That wall is gone and most of us have not built a replacement.

He never feared Microsoft. He feared two people. Microsoft was going to produce the kind of software that takes fifty thousand people to make, which is how you end up with four versions of Outlook. He calls it the resource curse. Small teams are forced to choose, and large ones can outsource their unresolved thinking into a project.

Out teach instead of outspend, but the loop is damaged. He credits the idea to Kathy Sierra: the best marketing is to out teach your competition. That was their entire strategy for two decades. He was also honest about what broke. Not the human part, the algorithm part. His followers no longer see what he posts unless it goes at least mildly viral, which severs the reciprocity that used to make giving things away work. This is why he values podcasts and newsletters, where subscribers actually receive things.

Costs are permanent, revenue is not. Senra read him a line from Andrew Carnegie: profits and prices are cyclical and subject to any transient force in the market, but costs can be strictly controlled, and any saving on cost is permanent. DHH's version is about control. He cannot decide whether a customer enters a credit card. He can decide whether to own his hardware instead of renting it. Running hospital IT, I have almost no revenue lever at all, but I have a great deal of authority over cost, and everything saved there is permanent.

I left out the last stretch of the interview, which covers an internal conflict at 37signals in 2021. It is a different subject with a very different context, and I would rather point you at the source than summarise it badly.

Original video: https://youtu.be/76rR68ktQvo (David Senra, "DHH: How to Build a Profitable Company Without Losing Control", about 1 hour 42 minutes)