Czemu produkcja oprogramowania tyle trwa?

Złożoność

Za każdym razem, gdy rozwiązujesz problem (nie tylko problem z oprogramowaniem), występują dwa rodzaje złożoności:

1. Podstawowa (wewnętrzna) złożoność - jest to zasadnicza treść problemu. Nie możesz rozwiązać problemu bez rozwiązania tej złożoności.
2. Przypadkowa złożoność - jest to wszystko co towarzyszy podejściu i narzędziom używanym do rozwiązania problemu. Nie jest to część rzeczywistego problemu, który rozwiązujesz.

Taki podział proponuje przynajmniej Fred Brooks w „No Silver Bullet - Essence and Accident in Software Engineering”. Dlaczego to jest istotne?

Coraz mniej zasadniczych problemów

Charakterystycznym trendem w produkcji oprogramowania na przestrzeni ostatnich 20 lat jest drastyczne zmniejszenie stosunku złożoności niezbędnej do przypadkowej. Zjawisko to doczekało się nawet nazwy „kompresja koncepcyjna” aby pokazać jak zmieniło to branżę na plus. Rozprzestrzenianie się frameworków i bibliotek open source było najpotężniejszą siłą zmniejszającą ilość przypadkowej złożoności systemów oprogramowania w ciągu ostatnich dwóch dekad.

Ilość kodu potrzebnego do rozwiązania problemów biznesowych w porównaniu do 20 lat temu została zmniejszona o rząd wielkości, więc można by pomyśleć, że tworzenie oprogramowania będzie o rząd wielkości szybsze niż wtedy. Tak się jednak nie dzieje, więc dlaczego nie? Co się dzieje?

Nowe wyzwania

Tworzenie oprogramowania jest łatwiejsze ale podczas gdy tak się dzieje, równolegle zachodzą inne zjawiska:

• Coraz więcej wymagamy od oprogramowania.
• Ilość oprogramowania w firmach rośnie lawinowo.
• Tempo wdrażania nowych technologii rośnie.

Chociaż do tworzenia oprogramowania coraz częściej wykorzystujemy zewnętrzne narzędzia i biblioteki, co powinno ułatwić tworzenie oprogramowania, stale wymagamy od niego coraz więcej. Gdybyśmy nadal próbowali tworzyć aplikacje internetowe ery roku 2000 przy użyciu nowoczesnych narzędzi, w rzeczywistości zaobserwowalibyśmy wielokrotny wzrost produktywności tworzenia oprogramowania. Jednak sytuacja nie stoi w miejscu, dziś oczekujemy, że oprogramowanie zrobi o wiele więcej niż 20 lat temu. To wymagało zmiany sposobu, w jaki tworzymy oprogramowanie.

Oto kilka przykładów zmian, które zaistniały w branży w ciągu ostatnich dwóch dekad:

• Wersjonowanie - kontrola źródeł istniała przez cały czas, ale nie zawsze była tak uniwersalna, jak jest teraz. Nie sądzisz, że to dodaje przypadkowej złożoności? Zapytaj juniora korzystającego z Git po raz pierwszy, co o tym myśli.
• Testowanie automatyczne - wprowadziliśmy wiele narzędzi do testowania i testowania. Wykonujemy testy akceptacyjne, testy integracyjne, testy jednostkowe itp. To dodaje znacznej ilości przypadkowej złożoności do projektu, choć oczywiście z zamian za zwiększone prawdopodobieństwo, że dostarczane oprogramowanie jest wysokiej jakości i funkcjonuje zgodnie z oczekiwaniami.
• Podział - wraz ze wzrostem złożoności systemu liczba możliwych połączeń i interakcji między komponentami rośnie kwadratowo. Oznacza to, że w pewnym momencie, jeśli oprogramowanie nie jest dobrze zaprojektowane, te interakcje będą rosły, dopóki oprogramowanie nie ugnie się pod swoją własną złożonością. Rozdzielanie systemów wiąże się z ogromną ilością przypadkowej złożoności.
• Specjalizacja - Ponieważ aplikacje internetowe stały się bardziej skomplikowane, zaczęliśmy wprowadzać wiele specjalizacji. Podczas gdy w 2000 roku nie było niczym niezwykłym, że inżynier oprogramowania projektował interfejs użytkownika, tworzył interfejs użytkownika i budował zaplecze aplikacji, w 2020 roku jest to już kilka odrębnych ról. Często zespół tworzący aplikację internetową będzie składał się z projektanta UI, projektanta UX, frontendowca, backendowca i DevOpsa. Te dodatkowe role pozwalają tworzyć oprogramowanie na większą skalę, ale narzędzia i procesy wymagane do koordynowania zespołów wprowadzają ogromną ilość przypadkowej złożoności.
• Automatyzacja infrastruktury - automatyzacja tworzenia i konserwacji oprogramowania to kolejna generacja złożoności prowadząca do tego, że DevOps staje się dedykowaną rolą w większości dużych zespołów.
• Częste wdrożenia - ponieważ aplikacje stają się coraz większe i stają się coraz bardziej złożone, musimy dostarczać je w mniejszych przyrostach, aby zmniejszyć ryzyko niepowodzenia. Aby to osiągnąć, mamy więc koncepcje ciągłej integracji i ciągłych wdrożeń (CI/CD). To znowu przypadkowa złożoność niezliczonych narzędzi i umiejętności potrzebnych do zbudowania i obsługi tych potoków.
• Wiele urządzeń i formatów – obecnie aplikacje muszą działać na komputerach stacjonarnych, laptopach i urządzeniach mobilnych na ogromnej liczbie platform a to zwiększyło złożoność procesu budowy oprogramowania.