4 ms·

I'm a big fan of trunk based development in the Churchillian sense. It's the worst form of development, except for all the others. I don't think it's for every

I'm a big fan of trunk based development in the Churchillian sense. It's the worst form of development, except for all the others. I don't think it's for every project, or even every feature in a given project. But there's a niche it works best for, and that niche happens to represent a massive percentage of all software engineering. The niche is, you're building a web app. It's some shitty Web 8.0 version of a Craigslist or something. No one wants to pay for formalized testing. No one really wants to spend a lot of time on quality. Arguably it's not that important to users. The year is Enshittified 2030 and they're lucky if they can even log into their online banking, let alone slide into someone's DMs on your platform. What's the solution? TBH it's not tripling down on good engineering process. (Don't get me wrong, good engineering process absolutely has a role, I'm merely suggesting that as you move from flight control software to online classifieds to your neighbor's recipe blog, that role diminishes in favor of less formal feedback.) The solution is radically forcing the code into the light of day in front of people who can say or do something about the biggest problems. The minor bugs will probably slip through this net, but the really nasty ones WILL get worked out if people on your team have to deal with them first, followed by an 'insider' circle of users, finally followed by the general public. That translates to certain buzzwords actually representing great ideas in this type of development, such as: feature flags, CI, pilot rollouts, and... trunk-based development. Just get the code/feature out in front of a couple people who matter, as early as the day it was written, and keep expanding until you're public.

urban_winter 1y ago
The idea that you can apply lower-quality engineering practices in some systems is totally wrong, I think. Good engineering practices will help you retain good developers, will allow you to maintain a sustainable development pace and will prevent you annoying your users so much that they stop using your system. I can't imagine any commercial project where this doesn't matter. Isn't this just another representation of the fallacy that it's possible to deliver faster by cutting quality? That's the kind of thing I expect to hear from ignorant stakeholders who know nothing about developing software, not on HN.
- IanCal 1y ago
  > The idea that you can apply lower-quality engineering practices in some systems is totally wrong, I think. But we obviously do this - practices are significantly different between beta release webapps and software on rivers we send to Mars. And that’s a good thing, the tradeoffs are wildly different. > Isn't this just another representation of the fallacy that it's possible to deliver faster by cutting quality? Do you think there’s anything that would increase quality on a project that you are on but also slow it down? It’s not always true - more haste less speed - but it’s not always false either.
- toast0 1y ago
  > The idea that you can apply lower-quality engineering practices in some systems is totally wrong, I think. > Isn't this just another representation of the fallacy that it's possible to deliver faster by cutting quality? If we use a real world analogy. You don't use the same engineering quality practices to build a sandwich as you do to build a space probe. It would be a mistake to x-ray verify connections between parts in a sandwich, but it would most likely be a mistake not to for a space probe. The engineering practice that needs to be done correctly is judging the error risk, predicting the consequences of errors, and mitigating errors where the cost of mitigation does not outweigh an estimate of the expected cost of damage from the error, including work to make things right. If you ship a sandwich where the spread was unevenly applied, inspection likely could have detemined this before shipping, but the cost to have another person carefully review each sandwich as it is being made outweighs the cost of the ocassional dry spot on the bread... Which may not be noticed or may not be bothersome... Worst case, a sandwich can be remade. Otoh, if an assembly comes apart in space on the way to another planet, it can't be fixed and the mission might be lost. If it takes weeks, months, or years for changes to be deployed, it makes a lot of sense to invest in procedures that improve quality before shipping, as responding to issues is expensive. If it takes minutes or seconds to deploy changes, measuring quality in production becomes more reasonable. Some changes are such that errors are likely to result in expensive cleanup, and those need extenstive testing before release... But things where the effects of errors will be mild can be pushed and if errors appear, a rapid response is often fine. It takes experience/wisdom to know which changes need more qualification and which are safe to try... and experience hopefully reduces errors too.

urban_winter 1y ago

The idea that you can apply lower-quality engineering practices in some systems is totally wrong, I think. Good engineering practices will help you retain good developers, will allow you to maintain a sustainable development pace and will prevent you annoying your users so much that they stop using your system. I can't imagine any commercial project where this doesn't matter. Isn't this just another representation of the fallacy that it's possible to deliver faster by cutting quality? That's the kind of thing I expect to hear from ignorant stakeholders who know nothing about developing software, not on HN.

IanCal 1y ago
> The idea that you can apply lower-quality engineering practices in some systems is totally wrong, I think. But we obviously do this - practices are significantly different between beta release webapps and software on rivers we send to Mars. And that’s a good thing, the tradeoffs are wildly different. > Isn't this just another representation of the fallacy that it's possible to deliver faster by cutting quality? Do you think there’s anything that would increase quality on a project that you are on but also slow it down? It’s not always true - more haste less speed - but it’s not always false either.
toast0 1y ago
> The idea that you can apply lower-quality engineering practices in some systems is totally wrong, I think. > Isn't this just another representation of the fallacy that it's possible to deliver faster by cutting quality? If we use a real world analogy. You don't use the same engineering quality practices to build a sandwich as you do to build a space probe. It would be a mistake to x-ray verify connections between parts in a sandwich, but it would most likely be a mistake not to for a space probe. The engineering practice that needs to be done correctly is judging the error risk, predicting the consequences of errors, and mitigating errors where the cost of mitigation does not outweigh an estimate of the expected cost of damage from the error, including work to make things right. If you ship a sandwich where the spread was unevenly applied, inspection likely could have detemined this before shipping, but the cost to have another person carefully review each sandwich as it is being made outweighs the cost of the ocassional dry spot on the bread... Which may not be noticed or may not be bothersome... Worst case, a sandwich can be remade. Otoh, if an assembly comes apart in space on the way to another planet, it can't be fixed and the mission might be lost. If it takes weeks, months, or years for changes to be deployed, it makes a lot of sense to invest in procedures that improve quality before shipping, as responding to issues is expensive. If it takes minutes or seconds to deploy changes, measuring quality in production becomes more reasonable. Some changes are such that errors are likely to result in expensive cleanup, and those need extenstive testing before release... But things where the effects of errors will be mild can be pushed and if errors appear, a rapid response is often fine. It takes experience/wisdom to know which changes need more qualification and which are safe to try... and experience hopefully reduces errors too.