A website called Laws of Software Engineering has assembled a broad catalog of principles, patterns and cautionary maxims used to reason about software systems and the organizations that build them. Rather than proposing a single development method, the collection brings together ideas that address architecture, project management, human behavior, testing and technical change.
Several entries focus on how systems grow. The catalog includes the observation that working complex systems generally evolve from simpler systems that already worked, alongside warnings that abstractions leak and that every application contains some complexity that can be moved but not eliminated. It also includes familiar guidance to avoid functionality before it is needed, keep designs as simple as practical and maintain one authoritative representation for each piece of knowledge.
Organizational structure is treated as inseparable from technical design. One listed principle says that systems tend to reflect the communication patterns of the organizations that create them. Others warn that adding people to a late project can delay it further and that individual productivity may fall as teams expand. The site also identifies the “bus factor”: the minimum number of team members whose absence would place a project in serious difficulty.
Time and estimation form another cluster. The collection notes that work tends to expand to use the time allotted, that projects often take longer than expected even after delays are anticipated, and that the final portion of implementation can consume a disproportionate share of the schedule. Together, these entries frame estimation as a recurring source of risk rather than a calculation that can be perfected once.
The testing and maintenance principles emphasize feedback. The catalog presents a pyramid with many fast unit tests, fewer integration tests and a small number of interface-level tests. It also warns that repeatedly using an unchanged test set becomes less effective over time. Related entries describe technical debt as anything that slows further development and encourage teams not to leave poor designs or incorrect decisions unrepaired.
Other parts widen the lens beyond engineering practice. The collection covers the tendency for a metric to lose value once it becomes a target, the danger of continuing with a choice solely because resources have already been invested, and the bias toward evidence that confirms an existing belief. It also includes principles about distributed systems, parallel processing and network effects.
The result is best read as a map of recurring engineering trade-offs, not a set of universal commands. Some entries summarize formal technical limits, while others are rules of thumb or social observations. Their value lies in giving teams concise names for patterns they can test against the specific constraints of a project.
