There's also another bit that I fail to understand.

If the Chinese Firewall guys wanted to DoS github, they could just do it. Playing synthetic traffic against github, for example.
Instead, we say that they hijacked their users computers, so they could generate traffic that in the end would have to go through the firewall.

From the firewall point of view, that wouldn't be a DDoS, because the attacker is always them, no distribution happens. It doesn't make sense, and it's a lot more work than just doing the DoS attack themselves.

Of course, MITM is something they can do, they might be doing that kind of thing, and hijacking clients computers for other reasons, but for this attack, it doesn't make a lot of sense.

In any case, you would need Amazon to actually enforce it.
While they do have more money for legal fees, they would risk a big PR issue if they tried to prevent some guy from working at Walmart after quitting Amazon. Also, the first guy with such a problem wouldn't have a lot of trouble finding someone to help them with legal fees, if only for the publicity.

This is probably just a scare tactic, to discourage people from leaving them, it is unethical, but not really enforceable.

Does that manual encourage bad code ?

The second one should also include "immutable". If it's hard to understand it will evolve easily to non working, and time spent on improvements can start to creep up very fast.

I have worked in very clever, solid code, but not easy to read. It was then maintained and extended by average, but competent programmers down the road, and turned into a big mess, only because it was so hard to understand.

In my experience, good code is easy to read, above all. That will make it easy to extend it coherently, find bugs and stuff. Also, if it doesn't work OK, it's easy to find out why. The single metric that saves time, money, and improves quality down the road is readability. Eveything else should be suject to that.

And, about the last point in the "article", "efficient", it's nonsense. Premature optimization is the root of all evil. You should _always_ follow the second rule of optimization (see http://c2.com/cgi/wiki?RulesOfOptimization ).

PHP can be good or bad, like any other code. Lately it's getting better.
As an example, do you think this looks bad? Looks pretty good to me.

  https://github.com/symfony/sym...

I have some awful, unreadable examples I could share in Java, PHP, Javascript and even C, but chosen language no longer forces you to write bad code. Maybe Perl, but I haven't seen it lately.

"OS" mentality is that it will be done when it's _done_. Not when it's _right_.
And it's tautologically true. You don't need management to change their mentality, only to _accept_ reality, and act accordingly. I know it might be too much to ask for, but it's not too much to ask.

While it does make sense to have a roadmap, release dates for new software are too often wrong. It's a good thing to keep yourself honest about expectations, and drive the development process, so you can get quality stuff, in reasonable timeframes, providing the greatest possible value.

Unrealistic expectations and pressure on estimates won't help you get there faster, or better. Being realistic will help your team improve estimations, and also help you complete stuff faster, and better.

You are right in your assessment, but there should be a solution for that.

Time and materials contracts can take care of the issues you are talking about. You can reject a pull request, but still pay for the hours.
It's a lot cheaper to pay for the hours than to fight over them. If it's an employee, help them get better, refine your specs, or maybe move them or replace them, if they are not fit for _that_ project. If it's a contractor, change contractors if they are bad.

If you are contracting software development, it's always better to assume some risks yourself, because that keeps your providers focused on helping you reach your objective, and not contract stuff. If you don't want to take risks, you shouldn't be developing software in the first place, but buying ready-made solutions.

.