Development, Analysis And Research

I tend to come across these little Axioms that make me smile when reflecting upon work, and I generally forgett all about them, as such I’ll post some up…

Axiom I: If you have not tested it, assume it is broken.

Axiom II: If someone changes it, they probably broke it.

Axiom III: Sometimes when it is not changed, it breaks too.

Axiom IV: What is broken on the test machine often works fine on the dev machine.

Axiom V:There is always another bug that a user can find.

And there is of course the first theorem of test, which is largely based on applying on the developer’s doubt of Axioms 2, 3, and 5 created by the circumstances of Axiom 4:

THEOREM I: Developers will often not believe there is a bug until it is proven to them, sometimes with extreme prejudice.

And of course the corollary to Axiom V:

There are at least as many bugs left to be found as there are users who haven’t yet run your code.

Thanks to Sara for pointing them out
Axioms of Web architecture

Simplicity, "Keep it simple, stupid!"

Keep It Simple Stupid is the most often forgotten principle in system design. The best systems are those that can perform the tasks with the least hardware, software and/or personnel resources. The more complicated and “state of the art” the system becomes, the greater the potential for waste, training excesses, errors, omissions and support. You can change a light bulb with one person holding the bulb and another turning the lamp, but isn’t it easier to just use two hands?

Modular Design

When you design a system, or a language, then if the features can be broken into relatively loosely bound groups of relatively closely bound features, then that division is a good thing to be made a part of the design. This is just good engineering. It means that when you want to change the system, you can with luck in the future change only one part, which will only require you to understand (and test) that part. This will allow other people to independently change other parts at the same time. This is just classic good software design and books have been written about it. The corollary, the TOII is less frequently met.

Tolerance

"Be liberal in what you require but conservative in what you do"
This is the expression of a principle which applies pretty well in life, (it is a typical UU tenet), and is commonly employed in design across the Internet.

Decentralization

This is a principle of the design of distributed systems, including societies. It points out that any single common point which is involved in any operation trends to limit the way the system scales, and produce a single point of complete failure.

Principle of Least Power

In choosing computer languages, there are classes of program which range from the plainly descriptive (such as Dublin Core metadata, or the content of most databases, or HTML) though logical languages of limited power (such as access control lists, or conneg content negotiation) which include limited propositional logic, though declarative languages which verge on the Turing Complete (PDF) through those which are in fact Turing Complete though one is led not to use them that way (XSLT, SQL) to those which are unashamedly procedural (Java, C).

The choice of language is a common design choice. The low power end of the scale is typically simpler to design, implement and use, but the high power end of the scale has all the attraction of being an open-ended hook into which anything can be placed: a door to uses bounded only by the imagination of the programmer.

If it’s Not Broken Don’t Fix it.

When upgrading hardware, software, systems etc., the motivation should be the substantial improvement of productivity and/or quality of output. Upgrading or changing systems for the sake of change or because it’s bigger or better, presents substantial risks to production and often costs more than the benefit.

The 90/10 Theory

When designing manual and automated systems, you get 90% of the benefits out of 10% of the effort. To get the extra 10% benefit, it takes 90% more effort. In that last 10% benefit (often bells and whistles) rests all your profit, time, failure and complexity.

RTFM - Read The Fucking Manual

Established by technicians long ago and now used heavily on the net, this axiom is the least followed by most computer users . While we have grown accustomed to poorly written documentation, or no documentation, usually you will find the answer to most situations in the manual.