Software Engineering Laws
a year ago
- #productivity-laws
- #engineering-management
- #software-development
- Parkinson’s Law: Work expands to fill the available time, emphasizing the importance of deadlines.
- Hofstadter’s Law: Projects always take longer than expected, highlighting the challenges in software estimation.
- Brooks’ Law: Adding more people to a late project makes it later, stressing the inefficiency of scaling teams mid-project.
- Conway’s Law: Organizations design systems that mirror their communication structures, suggesting strategic team structuring.
- Cunningham’s Law: Posting wrong answers online is an effective way to get correct information, useful for problem-solving.
- Sturgeon’s Law: 90% of everything is of low quality, urging focus on high-value features.
- Zawinski’s Law: Programs tend to expand until they can handle email, warning against feature creep.
- Hyrum’s Law: Users will depend on every observable behavior of an API, complicating feature maintenance.
- Price’s Law: A small fraction of a group produces most of the output, affecting team scaling strategies.
- Ringelmann Effect: Individual productivity decreases as group size increases, advocating for smaller teams.
- Goodhart’s Law: When a measure becomes a target, it loses its effectiveness, cautioning against metric misuse.
- Gilb’s Law: Any important metric can be measured in some way, promoting measurement over avoidance.
- Murphy’s Law: Anything that can go wrong will go wrong, advising thoroughness in planning and execution.