Everything Currently Done Managing Programming Is Wrong

All Current Programming Methodologies Are Wrong

Both Managers AND Programmers Are Responsible

Any useful form of engineering converges on standards of performance, error metrics, and gauges of time and effort.
Computer programming has done none of these.

So-called "computer science" is a branch of mathematics.
As such, it is extremely valuable discovering algorithms, theorems, and other mathematical truths.
As such, it is useless to direct the engineering of computer systems.

Any useful engineering discipline has standards for determining, measuring, reducing, and controlling errors.
This is absent in current programming practice.

Any useful engineering discipline has standards and references for predicting costs and durations for projects.
This is absent in current programming practice.

Any engineering discipline will not accept
  "trim 50% off your schedule and increase your deliverables".
This is common practice in programming management.

Any engineering discipline will not accept
  "change these deliverables which require totally changing your architecture without increasing any costs."
This is common practice in programming management.

Any engineering discipline will not accept
  "use these parts,
    you don't know how they work,
    the specs are secret,
    and the parts will fail in unpredictable and undetectable ways if you violate the secret specs,
      combine them with other parts,
      or exercise their unknown or undisclosed failure modes."
This is the definition of object programming.
This is common practice in programming management.

The previous are indisputable by anyone who has worked in the field for a non-trivial time.

I assert that there is a methodology which is real engineering and will
produce predictable, reliable, and cost-effective systems.
I have developed this based on a very large body of openly available work.
It is based on a very simple and well known engineering principle: KISS.

The ramifications of KISS are extremely pervasive.
The requirements on the process of making a reliable system are rigorous.
Managers must know and believe what they can and cannot get.

All of the requirements stated in the following essays are essential.
I will discuss an extremely simple mathematical justification for this statement in an essay to come.

If you are viewing this text on a typical computer system,
you have not read at least 60% of the text above.
This is an example of why current practice is wrong.
How can anyone produce correct systems when it is impossible to read the requirements?

Here are some essays. If you are enamored of current practice or pedagogical drivel, you will not like them.
Management does not reward dissonant views.
Your only reward for espousing the principles described will be the successful implementation of your projects.
In the normal course of commerce, that is only rewarded by a glancing blow by the brown-nosers who have better access to those in power.
Remember, there were decades when "You can't be fired for specifying IBM."
Now it's Microsoft.
Big deal.

If you have concrete evidence that I'm wrong, I'd like to hear about it.
I'm not interested in hearing "I don't make errors."
You may not, but unless you are the only person
   working on the project
   specifying it,
   implementing it,
   maintaining it forever,
   and marketing and selling it,
your argument is worthless, nonsense, and ridiculous.
I'm smarter than almost everyone I know and I make lots of mistakes.
I only know of two people who don't make mistakes coding,
and they do so by reviewing their work for great lengths of time
     and simplifying everything to the limits of possibility before committing it.