It's a debt though. Because people will forget it's there and then at some point someone changes a counter from milliseconds to microseconds and then the issue happens 1000 times sooner.
It's never right to leave structural issues even if "they don't happen under normal conditions".
In hard real-time software, you have a performance budget otherwise the missile fails.
It might be more maintainable to have leaks instead of elaborate destruction routines, because then you only have to consider the costs of allocations.
Java has a null garbage collector (Sigma GC) for the same reason. If your financial application really needs good performance at any cost and you don't want to rewrite it, you can throw money at the problem to make it go away.
I don't think this argument makes sense. You wouldn't provision a 100GB server for a service where 1GB would do just in case unexpected conditions come up. If the requirements change, then the setup can change, doing it just because is wasteful. What if we forget is not a valid argument to over engineer and over provision.
If a fix is relatively low cost and improves the software in a way that makes it easier to modify in the future, it makes it easier to change the requirements. In aggregate these pay off.
If a missile passes the long hurdles and hoops built into modern Defence T&E procurement it will only ever be considered out of spec once it fails.
For a good portion of platforms they will go into service, be used for a decade or longer, and not once will the design be modified before going end of life and replaced.
If you wanted to progressively iterate or improve on these platforms, then yes continual updates and investing in the eradication of tech debt is well worth the cost.
If you're strapping explosives attached to a rocket engine to your vehicle and pointing it at someone, there is merit in knowing it will behave exactly the same way it has done the past 1000 times.
Neither ethos in modifying a system is necessarily wrong, but you do have to choose which you're going with, and what the merits and drawbacks of that are.
The main reason it hate Excel is that people abuse it as a database. Having whole stretches full of vlookups but some single rows overwritten with manual input data.
It also chokes on sheets with only a few hundred thousand rows on my 16gb work laptop, something a real database can easily do.
I blame it on Microsoft making such a mess of access that people didn't understand it and started using excel as a database.
I'm glad it has a physical SIM still. I always use regular prepaid phone plans for my 4/5G backup but the providers don't like these being used with modems. So they have more options to block them with eSIM.
Yes it's in combination with KDE that it doesn't work well yet. Simpler window managers are ok. But big desktop environments still have major issues with freebsd's wayland. KDE for sure and I believe Gnome also (I don't use it).
Data centres have big halls, usually no windows whatsoever, and are wide and flat so windows are only possible at the edges. They're even worse for conversion than office buildings.
Better to raze them and build apartment buildings.
reply