Які ви знаєте закони, що притаманні розробці ПЗ?

Вітаю. З вами Артур! Хотів би поділитись законами в розробці ПЗ, які познаходив на просторах інтернету.

💡 Brooks’s Law

Adding [human resources] to a late software project makes it later.

Додавання нових учасників до проєкту, який не втискується у дедлайни, може ще більше затримати його через зростання витрат на координацію.

💡 Goodhart’s Law

When a measure becomes a target, it ceases to be a good measure.

Якщо націлитися на певний показник, поведінка людей почне змінюватися для його досягнення, навіть якщо це не допомагає досягти справжньої мети. Наприклад, коли ви починаєте міряти ефективність тестувальника по кількості створених багів або ефективність розробника по кількості рядків коду. Перший починає на кожний піксель створювати баг, а другий писати спагетті-код.

💡 Hyrum’s Law

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

Користувачі починають залежати від навіть неочікуваних поведінкових аспектів системи, що ускладнює зміни.

💡 Conway’s Law

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Архітектура програмного забезпечення часто відповідає структурі організації, яка його створила.

💡 Linus’s Law

Given enough eyeballs, all bugs are shallow.

Чим більше людей перевіряє код, тим легше знайти помилки.

💡 Hofstadter’s Law

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Реальність майже завжди перевищує очікувані терміни виконання завдань.

💡 Kernighan’s Law

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

Якщо ви пишете занадто складний код, його буде важче виправити.

Надмірно складний код ускладнює відлагодження і підтримку.

💡 Peter Principle

People in a hierarchy tend to rise to ‘a level of respective incompetence.

Людей часто просувають по кар’єрних сходах до тих пір, поки вони не досягнуть позиції, на якій не зможуть ефективно працювати.

💡 Pareto Principle

For many outcomes, roughly 80% of consequences come from 20% of causes.

Більшість результатів досягаються від невеликої частини причин, тому важливо фокусувати зусилля на найважливіших аспектах.

💡 Gall’s Law

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

Розвивайте ваші системи, ітеративно їх ускладнюючи.

💡 Parkinson’s Law

Work expands so as to fill the time available for its completion.

Чим більше часу виділяється на завдання, тим більше його займає робота.

💡 Wirth’s Law

Software gets slower faster than hardware gets faster.

Програми стають менш продуктивними з плином часу, навіть з поліпшенням обладнання.

💡 Knuth’s optimization principle

Premature optimization is the root of all evil.

Оптимізація на ранніх етапах розробки може призвести до значних проблем і ускладнень у майбутньому.

А чи знаєте ви ще якісь закони, що притаманні розробці ПЗ?

P.S.

Всім гарного дня та буду радий бачити у групі!