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.
> 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.
> 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.
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.