Some general opinions related to software development. Not trying to logically deduce any of these. I've just grown to found them true over the years.

Jfs' Law: All tree structured data sets are actually DAGs in disguise.

You define the problem. If you have a problem, try to make the problem simple enough so you can devise a solution.

Consistency is foolish: Don't be afraid to add code that doesn't fit in cleanly. That's better than hiding the problems. The right way to restructure the surrounding code might soon become apparent, improving overall architecture.

If you know how to scratch an itch, that doesn't mean you should. Procrastinate until it is a problem in actual practice.

In a solid architecture decisions are pushed out as far as possible. Delegation is the key. Decisions that are not strongly associated with the name of a procedure must not be made in that place.

Generalizations are always wrong.

Object-orientation generally sucks. Its antithesis is aspect-orientation and it works. Helper classes / modules are a code smell. They probably exist because the implementation of an aspect is scattered across the program source (across multiple datatypes).

If you can get away without materializing a concept in code, that's probably a good idea. Abstractions and taxonomies break easily. Large programs have many of these. Example: Metadata/Data, Objects/data-and-procedures, Complicated type systems/primitive machine types. Be aware of the cost of unwrapping concepts for other parts of the program where they don't fit. Example suggestions for minimizing that cost: Build OOP classes only as proxies to procedural code. Don't physically separate Data/Metadata (consider the great success of Unix filesystem files. They have (almost) no separate metadata. Instead such questions are delegated to individual file formats and implementations).

Reusable code is often not the best code. There is probably a lot of redundancy (cross-cutting concerns). Or alternatively, increased interface complexity, to the point where it's easier to just write a custom-tailored version of the code.

todo: "naming is a matter of perspective"

todo: "know your primitives and you can work with less abstraction"

Created: 2017-04-05
Last updated: 2020-02-15