Software Engineering Values

Apr 08, 2022

Definitions

First some definitions, otherwise the points made will be ambiguous

Simple: composed of few parts

Complex: composed of many parts all interacting with each other in intricate ways

Easy: does not require high levels of expertise to operate

Difficult: requires high levels of expertise to operate

Robust: Continues to operate reliably under many different conditions. Does not break easily.

Fragile: Tends to break a lot. Requires constant intervention and maintenance to keep in operation.

Products should work out of the box with the absolute bare minimum configuration needed (aim for zero).
- For a good discussion on the topic, see: https://handmade.network/fishbowl/config/
- Settings is for customizing experience. Configurations is what is required to make the system work at all. Systems can collapse due to small errors in configuration. A system that requires tons configuration is a fragile system.
- Configuration and settings *must* be discoverable via the UI and not be just relegated to config files whose location the user has to guess (or dig into manual pages to find out).
The UI should present as much information as possible about the current context. Nothing should be hidden behind menus and sub menus. UI should not waste space.
UI areas must be clearly demarcated. UI elements should have absolutely clear visibility. The user should understand from a cursory look whether something is a button or just a box with text in it. Reject the flat UI trend.

Eliminate dependencies. Build things internally. Don't outsource the core of your product. If it's outsourced, then anyone else can get it too, and then if you are successful copy cats will spring up to eat up all your market. Reject the fear of NIH.
Don't aim for exponential growth. Aim for a big but sustainable revenue stream. The company should be able to sustain itself without the constant need for investors pumping in money.
Money is an operational constraint (among many others) to manage, not the end goal to aim for. There must be something you want to make other than money to justify why the company exists.

Hire people whose competence you can trust, so you don't need to micromanage them.
Fussing over irrelevant details (fluff) creates a toxic culture. Focus on the essence.
Avoid processes that kill motivation, no matter what their supposed benefits are.
Firing is just as important as hiring.
Leadership roles should be clearly defined. If there's no leader, infighting (and bitterness) ensues as everyone tries to be a leader.
Assign responsibilities to individuals, not to "the team".
- When responsibility and ownership are diffused, nothing gets meaningfully done.
- Competent engineers thrive on ownership.

Approaching problem solving from first principles, not from analogy.
Understanding how computers work is essential for good engineering.
Performance is a feature. It has to be baked in from the start. It can't be added later.
It's important to consider the costs, not just the supposed benefits, of any tech/library/language/engineering-decision.
Invoking "industry best practice" is not a valid argument.
The important quality in a maintainable project is tractability.
- When something breaks, can we track the problem and fix it?
- Or is it just "nice when it works", but breaks in mysterious ways?
Static type checking is extremely important for keeping code tractable.
Unnecessary complexity gets in the way of tractability. Removing it is essential.