A Rule of Software on Usabilty

Make your software useful. That is the point without usefulness there is no need for existence.

If you write a function that is not useful, scrub it from your text editors as not to offend the blessed pixels. Do not fear throwing away non-useful parts of your code, better to cast away these parts rather than sacrifice the usefulness of the whole.

If it is useful to repeat yourself, do so. Repeating yourself in subtly different ways teaches your novices, which must be done well. If there is a common pattern for your task use it, until it is not useful anymore. Write your tests as soon as they will be useful, tests are always useful before giving your code to others. Separate your code into useful partitions. If the partitions are too big or too small the usefulness will be clouded as it is difficult to track the function and interplay between the partitions.

When the program is done, let it stand on its usefulness. If others do not find it useful, seek out more to judge your craft. If none count themselves blessed to have witnessed your skill, throw out the program. Better had the program not been born than to prop it up with false claims of usefulness or many words about its beauty, adherence to principles, or features that none have found useful.

Each programmer must look from within to find the metric of usefulness. Some programs are only useful to the programmer, others must be useful to a multiplicity of programmers, and few hold themselves to such high esteem as being useful to the unwashed non-programming masses. Do not make the program raise malcontent by seeking affection in those it cannot help.

The API can hold back the usefulness of your code. Write many useful programs with the API and minimize their length. Large APIs are weaker than small APIs, but both can be useful. Do not be afraid to erase parts of the API which were only scaffolding to find the better API, the masterpiece could not have been made without the scaffolding, but if it is left standing it will obstruct.

When the performance guru tells you speed is more important, ask them why they don't make their users write in assembly, why BLAS doesn't require you to pack your own matrices, and why the CMS doesn't make you connect to your own sockets. To discourage performance hacks give the programmer five lashes as these hacks are the enemy of abstraction, which can be useful. If the programmer persist in their hacks, let them continue as clearly the speed is useful.

When the enterprise architect recommends yet another abstract factory manager class, ask them why they started programming and at what point they decided to make others despise reading their code. Separate them from the strong, eager, useful programmers and burn their resumes so that others do not confuse their ways as useful.

If the functional zealot tells you your side effects destroy the formal analysis, explain to him that monads rhymes with gonads which are quite useful. Ask them to travel discalced to the far reaches of the empty quarter so they do not harm useful programmers ears. Remember these prophets ramblings as even they are sometimes useful. Teach them to the young, but always remind them of the first rule.

When your sales representative tells you to remove the useful parts of your code, give them wind and ask them to sell the liberated air. When your project manager wants features that are not useful, give them a shovel and ask them to remove dirt from the parched earth only to have them place it back again for they have forgotten the first rule and should be left to sisyphean tasks. When other programmers check in code that is not useful, give them the rule and ask them if they are on the path to manager or guru.