Software Aphorisms

In recent times I've come to think that I must have actually learned a thing or two about architecting and developing software. Much of this wisdom can be presented as short mantras that are "universally" true. (Or so it seems to me. Of course I've learned the hard way, so I take the necessary context for granted...)

Interestingly these mantras typically translate to life in general. I hope I can remember to collect them here when they pop up in my head.

Problems are not god-given. You define the problem. If you have a problem, try to make the problem simpler before looking for a solution.

Foolish consistency. 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 solve a "problem", that doesn't mean you should. Don't solve it unless it is a problem in actual practice. (premature abstraction / problem solving, KISS)

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 update: 2017-09-10