Comments

jbverschoor 5d
Those are two different things.. Nothing to balance about. But put it in a graph or drawing, and it means it's true and supported by 'science'
henriquecm8 5d
Release early, don't fix it
peteradio 5d
How do people disentangle "ship the incorrect thing and let customers let us know what they really want" vs "ship the correct thing but built incorrectly and let customers know why its wrong". I hate the second with a burning passion because it seems like its bound to give the impression that you really don't know what you are doing. I've been put into situations too many times where I just could not get the point across that "yes I understand that we may not be giving the customers what they want, but what you are telling me to build is clearly not correct" its maddening. Sorry if its off topic but it seems at least adjacent to the articles balance. This seems to happen with PMs who do not have a deep enough background in the technical detail and yet reject the feedback given because it will reflect that poor understanding. "Agile" environments seem to enable this kind of behavior. I'm beginning to think I need to pivot to PM in my career so I can avoid the madness as a developer.
hulitu 5d
> Customers often ask me, why pour time into updates when what I have runs just fine? The answer is that a bug in your old version might assert itself at the worst possible time and force you to forego sleep for the next five days to recover

Why not do proper testing ? I know it's expensive. And when you have an OS as an init system is even difficult. It is sad the the UNIX philosophy is dying being replaced with the Windows philosophy.

torstenvl 5d
Simple: Release Early. Release Often until it Ain't Broke. Don't change things that Ain't Broke.

I don't think there's much consternation over actual bugfixes. There's consternation over constantly-shifting UIs and APIs.

The only time there's any tension between those two things is when people conflate bugs with poor design. The messy but correct thing to do when you've correctly implemented a poor design is to maintain backward compatibility while also offering the option to use the newer, more correct behavior. See, e.g., strcat() → strncat() → strlcat()

jrochkind1 5d
I think libraries (used as dependencies by other software) and "top-level" software/applications (used by users directly, whether that user is a developer or not) -- have different pressures and concerns.

Libraries should be much more conservative. I don't think "release early and often" was said about libraries.

And yes, it's tricky that it's not always a clear line between these two categories. A unix command line utility is sort of top-level software, but also likely to be use in a scripted/automated fashion.

So it's not always cut and dry, but the more you are aware of software depending on your software, the more careful you should be with releases.

eloisant 5d
They're not opposite.

"If it ain't broke don't fix it" => don't try to "optimize" something that works well. Maybe it will be able to handle more load after your big refactor, but if it already handle the load nicely and there is no indication load will go up, don't bother.

"Release early and often" => release after each change, don't bundle everything into a big release that happen every 6 months.

The first one is about deciding what to do, the second one is how you release the work you did.

AaronM 5d
Error Budgets are your friend
silentsea90 5d
How about use Feature flags and ship daily? Decouple your release schedule from your product iteration/launch timeline.
sylware 5d
Grotesque generalities. The devil hides in the details: planned obsolescence and redhad (IBM) with its glibc symbol versionning frenzy and not a clean ELF ABI set of libs (as an example).

Yep. Open source is not from enough, lean and stable in time open source is required.

jjslocum3 5d
I would love to read a Malcom Gladwell book on this topic. It touches on a core truth, not only in engineering but in society as a whole. Three examples from different spheres:

In software, I've seen repeatedly how new hires with big ideas (and youthful confidence that they know a better way of doing things) will come into a company and want to rewrite things "properly." In one management position, much of my role involved the politics of defending a well-working, well-maintained, big-revenue-driving application from a steady onslaught of such ambitious exuberance.

At the time, I thought "this must be the same phenomenon that drives shrinkflation": new MBA arrives at pickle-making company, seeks to bolster their career by demonstrably saving the company millions, convinces execs to put one less pickle in each pickle jar, consumers won't notice; step 3: profit!! In 2022, when you buy a cereal box, it's half air on the inside. In 1980, it was only 20% air.

I also shake my head when media pundits equate the success of a particular congressional session with the amount of new legislation they pass. I can imagine no simpler way to cruft-paralyze a democracy (while following the rules) than "releasing laws early and often."

chuso 5d
Break it often and don't fix it.
gdsdfe 5d
“If it ain’t broke, don’t fix it” is the absolute worst mindset to have! I've seen systems that are literally garbage because of it.
ChrisMarshallNY 5d
Man, I feel this.

I worked for a corporation that was so change-averse, that we needed to buy our development systems on eBay.

They actually had a point, and it was hard to argue against, but I found it absolutely infuriating, as the solution was to plan for change, and establish a process to be constantly evaluating and refining for new developments.

Instead, it was "Wait until we can't bear it any longer, then have a huge screaming match meeting." A new budget would be approved for new machines (and, thus, new operating systems and development tools), processes would be updated, and that would sit, until it was no longer new.

As I said, it was hard to argue against, because it was a 100-year-old company that had been successfully delivering really high-end stuff, since Day One. They did that by being so conservative that they hadn't discovered fire, yet. Measure 300 times, cut once, etc.

When there was a problem, it escalated quickly (and was used as fuel to tighten things down even more), as the company was held to standards that are probably up there with NASA.

Speaking of NASA, I can't help but notice that this rather plucky little outfit, called SpaceX, seems to be running circles around them. They seem to have figured out how to "fail fast," yet also deliver insanely high Quality stuff.

Might be worth ignoring their CEO's tweets, and look at what they are doing...

PaulDavisThe1st 5d
TFA seems to try to pin DEC's collapse & failure on their committment to back compatibility. Yet Microsoft has essentially done the same thing with Windows, and has not suffered the way DEC did. Seems like a weak argument.
exabrial 5d
The problem is a bunch of overpaid devs conflate anything that isn't absolute bleeding edge as a "bug", and we get into and endless cycle of UI refreshes and updates that exist solely to exist.
pdpi 5d
Lord Vetinari in the Discworld lives by the mantra that "If it ain't broke, don't fix it". Other characters noted that, under his governance, "things that didn't work ... got broken."
temporallobe 5d
We have relevant case of this. We’re on Angular 8 and the app is working just fine - customer is happy, it’s pretty easy to maintain, well-tested and hardened, etc., but we are now facing having to update to 14.x “or else”. It’s gonna be a long and difficult migration.
bradwood 5d
These are not mutually exclusive. It seems like the whole premise here just lacking nuance.
arminiusreturns 5d
Release to prod so you can fix stuff in lower envs.
GnarfGnarf 5d
"If it ain't broke don't fix it"

Would you fly on an airline that followed this principle?

Wait till the engine fails before fixing it.

In the air.

jillesvangurp 5d
Reducing cycle times for changes minimizes integration testing effort. Effort and risk increases non linearly with the amount of change and time. So, release as often as you can to minimize the risk and effort while balancing the cost of doing so. Some release processes just involve a certain amount of heavy process that takes time and money. E.g. app store releases are a PITA so doing that multiple times per day is not worth it. Server updates on the other hand are fine. Create a PR, tests pass, merge it and it goes live right away. We automated that process. A decision to merge implies rolling out the change. The minimum cycle time is the time it takes to build and deploy (about 7 minutes for the PR and another 10 to deploy) plus whatever time we need to do a change. Some changes are as small as 1 character. We have a production branch that we merge to from our master branch. We test the and use the master branch intensively and merge to production multiple times per week. No point in sitting on changes that work fine. Get it out and create some value for your customers and company and keep feedback loops short as well.

Short cycle times is also why I use a rolling release linux distribution (Manjaro) and browser (Firefox). Always fresh and up to date. And even though I'm on the Firefox Beta channel I never have to deal with it breaking or being unstable. It's stable because they have frequent nightly builds. By the time builds hit the beta channel they are already rock solid. I was on the nightly channel for a while and never experienced many issues there either. Great example of short cycle times. With the Beta channel I'm a few weeks separated from changes happening and me seeing the feature. With the release channel it's another few weeks.

Not updating because it aint broken is very valid until the time comes when you finally have to upgrade and all hell breaks loose because you are two years behind on dealing with breaking changes and have to do a massive project to make it happen. It was getting increasingly more broken while you were doing nothing; you just did not know about it. It's still technical debt. And now you get to deal with the non linear effort to fix it and pay the price.

So, on all projects where I'm in charge we update everything very frequently. If something doesn't work I want to know ASAP and mitigate now instead of not even knowing stuff is not going to work for another few years. If you stay on top of changes like that, the effort for this is very low. Mostly stuff just works. Occasionally some library has an issue. And then we fix it, work around it or wait for the next version (and document why we can't update). Easy stuff. Basic project hygiene. The first thing I do when working on a project I haven't touched in a while is update dependencies. If I'm working on it all dependencies have to be current. I get annoyed with being a few minor versions behind. I might wait a few dot releases with major releases. But generally, I want to get that over with ASAP. If it breaks, I'll at least know that I need to deal with that. Rolling back is always an option.