software engineering maxims - LeFreq/Singularity GitHub Wiki

A good coder treats his code like a Samurai treats his sword: for perfect precision and durability. The _reason_ to use such a tool is another path. You could say it is related to understanding the problems of the world -- as is why to build it: to master the machine. This is what hones the Samurai him/herself.

  • There is always a way to solve any functional problem from the natural world within the computer. No matter the problem or challenge, unless it involves consciousness (beyond generating conclusions), there is a computer science solution to it. If you stepped into databases and information management (XML), you've stepped away from computer science and into information science. In the case of data structures, even philosophy (epistemology). If you've moved away from telling what the computer to do and into forming self-contained systems that operate on their own, you've also stepped away from computer science and into simulation (PROLOG and Verilog are two such examples) -- while they are rigorously defined (like computers are famous for), they do not tell the computer what to do, so they are not computer programming languages. This includes AI (a branch of applied psychology). As for generating consciousness, the best you can hope for is to simulate it.
  • There is always an elegant solution to any problem in software engineering: you just have to look for it. Elegant solutions are all of the following: efficient (not wasting CPU or memory resources), concise (not wasting programmer resources), precise (dealing with every corner-case needed), and correct (they do the job they're supposed to do).
  • One can always trade processing time for memory and vice versa. Need better processing performance? Use more memory. Need to use less memory? Use more processing time. A variable assignment, you could say, is where it meets 1:1. In other words, you can lower the needs of one arbitrarily low (but not 0), like getting O(1) search through a billion N. If you have no time constraints, sometimes you don't have to do any work at all. You can wait for the user to find the answer.
  • Any engineering challenge can be met with one of five solution-paths (macro/micro):
    1. Different HardwareArchitecture: better design that matches the problem domain.
    2. A layer of indirection (like pointers) or encapsulation (like functions): adding or reducing dimensionality.
    3. Greater precision: going deeper into the code (like bit -level tweaking).
    4. refactor the language, so you can think in the problem's natural surroundings. Just as good writers in human language invent new, sophisticated words to express complex thoughts with better precision and brevity in their language, so too must computer languages evolve to express concepts more elegantly.
    5. Adding more processing power or memory, but see #1.
  1. If you've ran out of time or budget (or interest), there's always the hidden sixth option: shift control to the user.
  • Any design that requires endless processing availability and memory is bad science, making bad choices that will effect the whole life-cycle of the product. It's poor science, because the machine is doing the work, not the computer scientist. Such designs can be replaced by employing maxims above.
  • Design deficiencies are heralded by one of 4 measurable factors:
    1. excessive I/O (annoying, unnecessary, or ugly screen writes, thrashing of you harddisk)
    2. thrashing of your memory
    3. heat or noise from the hardware
    4. crumbs of data left around after execution
  • Unlike mechanical engineering, one can achieve 100% theoretical efficiency, 100% of the time. It's just that no one knows when the true mastery of the problem will come about in the world to make such perfection.
  1. Master your tools or they will master you. People get confused when they don't understand the underlying design of things. A true engineer should try to understand everything and continually measure and monitor their code and machine use.
  2. Most every program can be diagnosed (what is going wrong?) and queried (what is it`s design?) with profiler. A engineer should always have one available. One can't depend on having source code, but a profiler should be able to know where function calls are being made (by looking for Assembly CALLs and RETurns, for example) and watch what is going on.
  3. Stay pure. The test of your skillz is how well you can figure it all out without anyone else looking or doing your heavy labor and holding things aloft for you to buffer your lack of knowledge.
See also: Merge:

Singularity

⚠️ **GitHub.com Fallback** ⚠️