My – programiści poświęcamy zbyt wiele czasu na sprawy o niskiej wartości biznesowej. Rozwiązujemy 🔨 problemy, które mogą się nie wydarzyć. Przeciwdziałamy zapobiegawczo sytuacjom, których prawdopodobieństwo wystąpienia jest mniejsze niż 1% poświęcając na to olbrzymie pokłady energii, czasu oraz nadwyrężając budżet 💸 inwestora… Tytułowy overengineering może objawiać się na wielu płaszczyznach – definiując jednak najważniejsze trzy – może dotyczyć on:

▶️ rozwiązań funkcjonalnych, które nie są wykorzystywane przez klientów aplikacji,
▶️ architektury, która rozwiązuje lub „zapobiega” nie istniejącym problemom,
▶️ kodu, który przewiduje zmiany w obszarze, który się nigdy nie zmieni.

Podczas tego odcinka podcastu, zahaczamy o tematy związane z praktykami Extreme Programming wspomagającymi rozwiązywanie problemów w łatwy i prosty sposób, starając się odpowiedzieć na pytanie:

Kiedy nasze rozwiązania są zbyt przekombinowane?

Wychwycenie odpowiedniej równowagi pomiędzy rozwiązaniem technicznym, a problemem biznesowym jest bardzie ciężkie. Podczas tego odcinka podcastu Dev:Cast 📢 staramy się określić co odbierane jest w sposób negatywny jako overengineering.

Warto również poświęcić kilka minut na świetny artykuł "How To Accept Over-Engineering For What It Really Is".

Mam do Ciebie jednak dodatkowe pytania:

🔹 Spotkałeś się kiedyś z rozwiązaniami, które technicznie wyprzedzały wymagania projektu o lata świetlne?
🔹 Kto powinien dbać o zachowanie równowagi pomiędzy dostarczaniem, a rozwiązaniem technicznym?
🔹 Czy wszystko zawsze musi być w 100% doskonałe technicznie?

Jeżeli chcesz, to podziel się swoją opinią, zostawiając nam krótki komentarz pod artykułem. Będziemy bardzo wdzięczni za rozpoczęcie konwersacji 👌 W końcu warto się wymieniać doświadczeniem – co nie? 😎