You would think that the tech types around here would understand how marginal rates work, it is a fairly straight-forward math and logic problem.
On a related note, I wonder why software is so buggy?

>>Also the repayment of the debt is a flat rate on all earnings, that increases depending on gross earnings.

That is why rational tax systems don't apply higher rates on all earnings, but only to the next dollar earned. That way, every dollar earned results in more take-home pay.

It is kind of funny that the Australian UNIVERSITY debt system failed both math and logic.
Probably more a reflection on the intelligence of lawmakers than of university types.

>>Of course, if a company doesn't avoid layoffs, those laid off workers find their pay and hours cut a lot more

Correct.
It is a good solution for one company - it will not work at all when applied to all companies.

>>(Hey, most of the last 10% is taxes anyway, right)
Not Right.
The idea that at a certain point, the govt takes most of your earnings in taxes is an urban legend.
For anybody working by the hour, there is no "tipping point" where the govt keeps most of each additional dollar - it is just untrue.

>>If everyone did this (4x9hr days), we could avoid tons of layoffs nationwide.
A company can avoid layoffs by cutting hours and pay.
If everybody at every company had their hours and pay cut, their bills remain the same, so the workers' spendable income after covering expenses is either gone or greatly reduced - You have just created a recession.

>>that's what prototypes, iteration, and capacity planning are for
So, we are in complete agreement that performance is not an end stage activity.
Good!

OH,
So sorry, I thought we were discussing the merits of throwing more hardware at bad code.
I had not realized this was the discussion for the semantics of the word "optimization."
Bitter experience has taught me that performance must start with design optimization, long before code optimization.

Sorry for the snarl, I have been working 6 weeks on "optimizing" a rather critical piece of code where performance was a complete afterthought.
We have managed to speed it up by an order of magnitude, but poor performance is "baked in" to the design at every level, so there is only so much we can do.

If the first time you ever address performance is by "measuring what's slow", then performance was indeed an afterthought - after design, after coding, after testing.

If you only start thinking about performance that late in the game, your design will probably include more than one peformance degrading decision that is just too painful to rewrite.

As a database guy, I would say that:
Database locking issues with a poor design won't be fixed no matter how much hardware you throw at it, it will just lock up faster.
Database structures are one of the first products of development, and many (most) developers just try to model the data without any thought to performance.
The other terrible mistake that many coders make is to process records and fields one at a time instead of using bulk operations.

The old saw about "Premature Optimization is Evil" is false:
Making performance a late afterthought guarantees doom that no amount of hardware can fix.

When it is busy at the post office, they go on break, the line be damned. Employees just wander around behind the counter in full view of the long long lines - there is no urgency at all.

All the big retailers schedule extra help during busy business times. When it is extra busy at any modern store, they call all the employees to the cash registers - even the managers will man the registers when it is busy.

Say what you want about private enterprise, but it is hard to argue that they don't care about taking your money! If the guy down the street is better at taking your money, he will do it and the first guy will improve or go out of business.

With government, there is no guy down the street to push for improvement. It is that simple.

Biking is good. Be more than careful - a few drivers are hostile to sharing the road and most won't notice you. Cut carbohydrate consumption - high carb consumption makes you fat in the middle. Diabetes is an occupational risk for programmers as we get older. Many of the fat programmers my age (50) are diabetic. Another good reason to cut carbohydrates and increase exercise.