I agree completely. That sounds much better than my current strategy of delivering incomplete and broken products at unpredictable intervals.

My highly specialised sarcasm sensors (honed in the UK) suggest that this is not in fact your current deliberate strategy; that said, I have worked for so many groups and companies where that is exactly what happens, even if they think they're planning for something else to happen, and it's obvious to pretty much everyone involved that that is what is happening and will keep happening.

I was being humorous, but also telling the truth!

I went straight from hobby programming to freelancing, so I've been "rediscovering" best practices the hard way.

I did actually intend to do things properly, but client asked "can it be done faster" and I thought "sure I'll just ship fast and then rewrite it later"... ha! Project became so unmaintainable, development ground to a halt. (I am doing the rewrite now...)

Turns out sometimes my job is to say "no."

This is the side of software where soft skills are critical. Navigating when and how to say no can be extremely difficult, but it’s arguably crucial to operating effectively and sustainably.

Early in my career, everything was a yes and it cost me a lot of sanity. It rarely cost me clients because I was so diligent about keeping things on the rails, but that seemed to come with an inversely proportional cost to my well-being.

It took me a long time to realize that saying no is kind of like saying yes; you’re saying yes to getting the project done on a reasonable timeline and with the budget the client has, and most importantly, with your happiness intact. Saying yes at the wrong time can be saying no to finishing the project at all. It’s the right, and in a sense “nice” thing to do for everyone involved.

If you’re a chronic people pleaser, this kind of work can be extremely taxing (speaking from experience).

More to the point, it's much better than delivering incomplete yet working products quickly and regularly, complete yet broken products quickly and regularly, complete and working products slowly and regularly or complete and working products quickly and irregularly.

As I always tell my team: fast, cheap, good; pick three.

In my work they say: fast, cheap, good -- you can't have any of these.

Oncology?

Or defense contracting?

healthcare?

Thanks. Hot coffee just came out of my nose.

Ah, you sound like the vendor we've just fired.

I wish I was joking.

I’ve been going with “set expectations high and then pivot to new high expectations.” It compliments your strategy pretty well.

Well, that's my main strategy for my personal projects.

But why can't you just do it faster?

To go fast, stay humble and use boring technology.

.. in a simple and flexible way.

> That said, some devs interpret "quick" to mean "sloppy", which is not correct.

Totally agree, but I've seen some devs completely melt when we need to go fast/iterate. For them, they really do produce sloppy work when they go too quickly. Many "big thinker" types are like this. Not defending it, just an observation.

With a good sales team, you can land customers who don’t see all the features they need, because you’re routinely delivering a solid if simple product that gets major new functionality a few times a year and if you just hold on we will get your feature to the top of the list.

Those paying customers are where your MRR comes from. Another case of perfect being the enemy of good.

There is high overlap between customers who leave because their needs aren't met immediately and customers whos needs will never be met.

I agree, and would add "(nearly)-no software regression" (no "a feature that has worked before stops working"), and never twice the same one.