upvote
There's nothing more permanent than a temporary fix. If deadlines are causing those stopgaps, the aggressive deadlines are the root problem.
reply
> There's nothing more permanent than a temporary fix.

That should be one of those Tech culture “laws.”

I suspect that the dependapocalyse is a significant factor. When every part of an operation has multiple context rebuilds, and resources are not shared across module boundaries, you get inefficient behavior.

But I’m skeptical that there’s a will to rethink that.

reply
> That should be one of those Tech culture “laws.”

We already have something:

"Nothing is so permanent as a temporary government program."

Milton Friedman, Tyranny of the Status Quo

reply
Thanks for that.

I feel that there is a bit of a difference, though, because that’s really a cynical (and probably accurate) observation on the behavior of bureaucracy, and I feel the temporary fix thing is of a “finer granularity,” and applies to basic human nature.

reply
In my experience, many of those deadlines are commonly the only reason the company continues to exist as well.

The root of the problem is much more deeply ingrained in our economic system.

reply
I swapped the engine on my lawn mower ~3yr ago because it no longer had any compression and was very hard to start. The new engine has an electric starter. I didn't have time to fabricate a proper battery tray so I ratchet strapped a 2x4 to the gas tank and strapped the battery to that. It stayed that way until last month when I finally had time to weld up a battery tray.

Sometimes when some janky p.o.s. solution works well enough, it truly is good enough.

reply
Honestly, after years of seeing this play out, a lot of devs really lack the judgement to know when something is good enough to deliver and will endlessly delay projects to “ do the right thing”
reply
Absolutely. It’s one of the defining characteristics of what makes someone a capable senior in the role IMO.

I have known a lot of extremely talented developers, some with more technical skill than me, that simply failed at their job because they couldn’t come to terms with the fact that their job isn’t to produce the most perfect code possible for the problem.

reply
In my experience, I have only developed internal enterprise software for my entire career. Most of this stuff is gloried CRUD. Above all: Ship early and ship often. You don't get paid more for having less bugs. (Of course, don't ship crap, but you don't need perfection.) Also, often the specs (in my line of business) are unwritten, so you learn more by releasing quickly, then watching (internal) customers use the product and provide feedback.
reply
Totally agree. In these days of fast devs it's common to see PO's excitement reducing deadlines and assumimg a dev can deliver 5 feats in a day instead of trying to stabilize and fix bugs. Sad
reply
No deadline, no product.

Shipping is very important, sometimes more important than what you ship :)

reply