Wyjaśnienie entropii oprogramowania: przyczyny, skutki i środki zaradcze

Ten artykuł jest skierowany do programisty lub kierownika projektu, który jest ciekawy, czym jest entropia oprogramowania, jakie są praktyczne skutki ich pracy oraz jakie czynniki przyczyniają się do jej wzrostu.

Podstawowym celem jest stworzenie świadomości entropii oprogramowania, ponieważ jest ona czynnikiem we wszystkich formach tworzenia oprogramowania. Ponadto badamy sposoby, za pomocą których entropii oprogramowania można przypisać konkretną wartość. Tylko poprzez ilościowe określenie entropii oprogramowania i obserwację jej wzrostu w kolejnych wydaniach możemy naprawdę zrozumieć ryzyko, jakie stanowi dla naszych obecnych celów i planów na przyszłość.

Co to jest entropia oprogramowania?

Entropia oprogramowania wywodzi swoją nazwę od głównej cechy entropii w świecie rzeczywistym: jest to miara chaosu, która albo pozostaje taka sama, albo rośnie w czasie . Innymi słowy, jest to miara nieodłącznej niestabilności wbudowanej w system oprogramowania w odniesieniu do jego modyfikacji.

Niestety entropii oprogramowania rzadko przypisuje się znaczenie, na jakie zasługuje.

Nie bierze się pod uwagę tego, gdy wyciąga się kogoś z zespołu programistycznego, przedwcześnie rozpoczyna cykl rozwoju lub wdraża „szybkie poprawki” — momenty, w których w rzeczywistości jest najbardziej prawdopodobne, że się rozwinie.

Tworzenie oprogramowania to sztuka i handel, którego podstawowe elementy konstrukcyjne są źle zdefiniowane. Podczas gdy budowniczowie pracują z cementem i gwoździami, programiści pracują z logicznymi twierdzeniami i zestawem założeń. Nie można ich trzymać w dłoni i badać, ani też nie można ich uporządkować z dokładnością do jednej ósmej cala. Chociaż przypadkowy obserwator może pokusić się o porównanie rozwoju oprogramowania z konstrukcją, poza kilkoma powierzchownymi podobieństwami, takie postępowanie przynosi efekt przeciwny do zamierzonego.

Pomimo tych trudności, możemy jednak określić wytyczne, które pozwolą nam zrozumieć źródła entropii oprogramowania, zmierzyć stopień zagrożenia, jakie stanowi dla naszych celów, oraz (jeśli to konieczne) jakie kroki można podjąć, aby ograniczyć jego wzrost.

Proponowana definicja entropii oprogramowania jest następująca:

gdzie I wywodzi się z liczby nieoczekiwanych problemów wprowadzonych podczas ostatniej iteracji rozwoju, C jest postrzeganym prawdopodobieństwem, że wprowadzenie zmian w systemie spowoduje teraz nowe I > 0, a S to zakres następnej iteracji rozwoju. Ogólnie wartości E poniżej 0,1 są uważane za dobre. E 0,5 jest uważane za wysokie, a wartości powyżej 1,0 są przytłaczające.

Pojęcie iteracji programistycznej jest integralną częścią naszego zrozumienia entropii oprogramowania. Są to cykle aktywności, które prowadzą od jednego zachowania systemu do drugiego. Cele jakie stawiamy sobie podczas iteracji oprogramowania nazywamy jego zakresem . W rozwoju oprogramowania takie cykle obejmują modyfikację lub rozszerzenie podstawowego kodu oprogramowania.

Wszystkie modyfikacje kodu zachodzą w iteracji programistycznej, nawet jeśli ci, którzy je przeprowadzają, nie myślą o nich w ten sposób. Oznacza to, że mniejsze organizacje, które szczycą się budowaniem swoich systemów przy użyciu „szybkiej i brudnej” metodologii — z niewielkim lub żadnym gromadzeniem wymagań lub analizą — nadal stosują iteracje programistyczne, aby osiągnąć swoje cele. Po prostu ich nie planują. Podobnie, nawet jeśli zachowanie zmodyfikowanego systemu odbiega w jakiś sposób od naszych intencji, to i tak udało się to osiągnąć za pomocą iteracji programistycznej.

W rzeczywistości ryzyko, że tak się stanie, jest dokładnie tym, co nasza świadomość entropii oprogramowania ma wyjaśniać, a nasze pragnienie jej pomiaru ma na celu ograniczenie. W praktyce możemy zatem zdefiniować entropię oprogramowania w następujący sposób.

Każdy system ma skończony zbiór znanych, otwartych problemów I ₀ . Pod koniec następnej iteracji deweloperskiej pojawi się skończony zestaw znanych, otwartych problemów I ₁ . Wrodzona entropia systemu określa, jak bardzo nasze oczekiwania dotyczące _I1 będą prawdopodobnie różnić się od ich rzeczywistej wartości i jak bardzo różnica ta prawdopodobnie wzrośnie w kolejnych iteracjach.

Skutki entropii oprogramowania

Nasze praktyczne doświadczenie skutków entropii oprogramowania zależy od tego, w jaki sposób wchodzimy w interakcję z danym systemem.

Użytkownicy mają statyczny widok oprogramowania; interesują się tym, jak zachowuje się teraz, i nie przejmują się wnętrzem systemu. Wykonując predefiniowaną akcję, użytkownicy zakładają, że oprogramowanie zareaguje odpowiednim predefiniowanym zachowaniem. Jednak użytkownicy są najmniej przygotowani do wydedukowania poziomu entropii w oprogramowaniu, z którego korzystają.

Entropia oprogramowania jest powiązana z pojęciem zmiany i nie ma znaczenia w statycznym systemie. Jeśli nie ma zamiaru zmienić systemu, nie możemy mówić o jego entropii. Podobnie system, który jeszcze nie istnieje (tzn. następna iteracja jest właściwie pierwszą w jego istnieniu) nie ma entropii.

Oprogramowanie może być postrzegane jako „zapluskwione” z punktu widzenia użytkownika, ale jeśli w kolejnych iteracjach programiści i menedżerowie realizują swoje cele zgodnie z planem, musimy stwierdzić, że entropia w systemie jest w rzeczywistości dość niska! Doświadczenie użytkowników mówi nam zatem bardzo niewiele, jeśli w ogóle, o entropii oprogramowania:

• Twórcy oprogramowania mają płynny pogląd na oprogramowanie. Zajmują się tym, jak system działa obecnie, tylko w takim zakresie, w jakim musi zostać zmieniony, a także szczegółami, jak działa, aby opracować odpowiednią strategię.

• Menedżerowie mają prawdopodobnie najbardziej skomplikowany pogląd na oprogramowanie, zarówno statyczne, jak i płynne. Muszą zrównoważyć krótkoterminowe potrzeby z wymaganiami biznesplanu, który rozciąga się dalej w przyszłość.

Osoby w obu tych rolach mają oczekiwania. Entropia oprogramowania objawia się, gdy te oczekiwania są zepsute. Oznacza to, że twórcy oprogramowania i menedżerowie robią wszystko, co w ich mocy, aby ocenić ryzyko i zaplanować je, ale — wyłączając zakłócenia zewnętrzne — jeśli ich oczekiwania są mimo wszystko rozczarowane, dopiero wtedy możemy mówić o entropii oprogramowania. Jest to niewidzialna ręka, która przerywa interakcje komponentów, które nie były objęte zakresem, powoduje niewytłumaczalne awarie serwerów produkcyjnych i wstrzymuje terminową i opłacalną poprawkę.

Wiele systemów o wysokim poziomie entropii opiera się na konkretnych osobach, szczególnie jeśli są młodsi członkowie zespołu programistów. Ta osoba posiada taką wiedzę, że inni nie mogą wykonywać swoich zadań bez jego „cennego” wkładu. Nie można go uchwycić w standardowych diagramach UML lub specyfikacjach technicznych, ponieważ składa się z amalgamatu wyjątków, przeczuć i wskazówek. Ta wiedza nie jest uzależniona od logicznie spójnych ram i dlatego jest trudna – jeśli nie niemożliwa – do przekazania komukolwiek innemu.

Załóżmy, że z wielką determinacją i wysiłkiem taka organizacja jest w stanie odwrócić się i ustabilizować swój dział IT. Wydaje się, że sytuacja uległa poprawie, ponieważ po zatrzymaniu rozwoju oprogramowania wszelkie postępy są zachęcające. Jednak w rzeczywistości spełniane oczekiwania są niskie, a osiągnięcia nieciekawe w porównaniu z wzniosłymi celami, które były w zasięgu, gdy entropia była wciąż niska.

Kiedy entropia oprogramowania przytłacza projekt, projekt zawiesza się.

Nie może być więcej iteracji programistycznych. Na szczęście taka sytuacja nie pojawia się od razu. Powolny, ale gwałtowny marsz w kierunku krawędzi urwiska to coś, co przechodzi każdy system. Bez względu na to, jak dobrze zorganizowana i wydajna może być pierwsza wersja, w kolejnych iteracjach rozwoju jej entropia — a zatem ryzyko, że coś nieoczekiwanie pójdzie nie tak — będzie rosła, chyba że zostaną podjęte określone kroki, aby temu zapobiec.

Entropii oprogramowania nie można zmniejszyć. Podobnie jak entropia w prawdziwym świecie, tylko rośnie lub pozostaje taka sama. Początkowo jego efekty są znikome. Kiedy zaczynają się manifestować, objawy są łagodne i można je maskować lub ignorować. Ale jeśli organizacja próbuje zwalczać entropię oprogramowania dopiero po tym, jak stała się ona dominującym ryzykiem w projekcie, ze smutkiem okaże się, że jej wysiłki są daremne. Świadomość entropii oprogramowania jest zatem najbardziej użyteczna, gdy jej zakres jest niski, a negatywne skutki minimalne.

Nie wynika z tego, że każda organizacja powinna przeznaczać środki na ograniczenie wzrostu entropii w swoich produktach. Większość oprogramowania, które jest obecnie opracowywane — w szczególności oprogramowanie zorientowane na konsumenta — ma stosunkowo krótki oczekiwany czas życia, być może kilka lat. W tym przypadku jego interesariusze nie muszą brać pod uwagę skutków entropii oprogramowania, ponieważ rzadko stanie się ona poważną przeszkodą, zanim cały system zostanie odrzucony. Istnieją jednak mniej oczywiste powody, aby rozważyć skutki entropii oprogramowania.

Rozważ oprogramowanie, które obsługuje infrastrukturę routingu Internetu lub przesyła pieniądze z jednego konta bankowego na drugie. W danym momencie w produkcji jest co najmniej jedna wersja tego oprogramowania, a ich zbiorowe zachowania można udokumentować z dość dużą dokładnością.

Tolerancja systemu na ryzyko jest miarą tego, ile i jakiego rodzaju nieoczekiwane zachowanie możemy wygodnie dopuścić z jednej iteracji rozwoju do następnej. W przypadku wspomnianych typów systemów tolerancja na ryzyko jest znacznie niższa niż, powiedzmy, oprogramowania, które przekierowuje połączenia telefoniczne. To oprogramowanie z kolei ma niższą tolerancję na ryzyko niż oprogramowanie, które napędza koszyk wielu komercyjnych witryn internetowych.

Tolerancja na ryzyko i entropia oprogramowania są ze sobą powiązane w tym sensie, że entropia oprogramowania musi być minimalna, aby mieć pewność, że podczas następnej iteracji rozwoju pozostaniemy w granicach tolerancji ryzyka systemu.

Źródła entropii oprogramowania

Entropia oprogramowania wynika z braku wiedzy . Wynika to z rozbieżności między naszymi założeniami wspólnotowymi a rzeczywistym zachowaniem istniejącego systemu. Ten fakt wyjaśnia, dlaczego entropia oprogramowania ma znaczenie tylko w kontekście modyfikacji istniejącego systemu; to jedyny moment, w którym nasz brak zrozumienia będzie miał jakikolwiek praktyczny skutek. Entropia oprogramowania znajduje najbardziej podatny grunt w systemie, którego szczegóły nie mogą być zrozumiane przez pojedynczą osobę, ale są rozsiane po całym zespole programistów. Czas też jest potężną wymazywaniem wiedzy.

Kod jest wyrazem szeregu logicznych twierdzeń. Kiedy zachowanie oprogramowania (a tym samym jego kod) nie odpowiada logice, którą ma wyrazić, możemy mówić o jego wrodzonej entropii. Taka sytuacja może wystąpić na trzy sposoby: logika jest dobrze znana i odbiega od jej wyrażenia, istnieje wiele sposobów rozumienia logiki, którą kod ma wyrażać, lub logika nie jest dobrze znana.

• Pierwsza sytuacja – logika jest dobrze znana i odbiega od jej obecnego sformułowania – jest najłatwiejsza do rozwiązania, ale też najmniej powszechna. Tylko bardzo małe systemy utrzymywane przez być może dwóch uczestników, programistę i osobę odpowiedzialną za biznesplan, będą należeć do tej kategorii.

• Druga sytuacja – logika nie jest dobrze znana – jest rzadka. Pod każdym względem iteracja programowania nie może się nawet rozpocząć. Jeśli w pewnym momencie wszyscy interesariusze zgodzą się, prawdopodobnie staną w obliczu pierwszej sytuacji.

Ludzki umysł interpretuje swoje doświadczenia, skutecznie je filtrując i modyfikując, próbując dopasować je do osobistych ram. W przypadku braku efektywnych nawyków rozwojowych – opartych na swobodnej wymianie pomysłów, wzajemnym szacunku i jasnych oczekiwaniach – interpretacji tego, jak obecnie funkcjonuje system, może być tyle, ilu jest członków zespołu. Cele zespołu dotyczące bieżącej iteracji rozwoju mogą same w sobie być sporne.

Wielu programistów chroni się przed tą sytuacją, wzmacniając własne, unikalne rozumienie tego, czego się od nich wymaga i jak system „powinien” być zorganizowany. Z drugiej strony menedżerowie i inni interesariusze mogą nieświadomie dążyć do zmiany założeń innych członków zespołu w chybionej próbie ułatwienia sobie życia.

Dotarliśmy teraz do najczęstszego źródła entropii oprogramowania: istnieje wiele niekompletnych interpretacji logiki, którą system ma wyrazić. Ponieważ istnieje tylko jeden przejaw tej logiki, sytuacja jest z definicji problematyczna.

Jak powstaje ten brak wiedzy? Niekompetencja to jeden ze sposobów. A jak już widzieliśmy, brak zgody co do celów kolejnej iteracji rozwoju to kolejna rzecz. Należy jednak wziąć pod uwagę inne czynniki. Organizacja może twierdzić, że stosuje metodologię rozwoju, ale potem przypadkowo porzuca niektóre lub wszystkie jej aspekty. Deweloperzy oprogramowania mają następnie za zadanie wykonać niejasne zadania, często otwarte na interpretację. Szczególnie narażone na to zjawisko są organizacje wdrażające zmiany w swojej metodologii rozwoju, choć nie są to bynajmniej jedyne. Konflikty osobiste, których kierownictwo nie jest świadome lub w inny sposób nie jest w stanie rozwiązać, mogą również prowadzić do niebezpiecznej rozbieżności między oczekiwaniami a wynikami.

Istnieje drugi, ważniejszy sposób, w jaki tracimy wiedzę techniczną o produkcie: w transferze. Utrwalanie wiedzy technicznej na papierze stanowi wyzwanie nawet dla najbardziej biegłych pisarzy. Powodem jest to, że to, co należy przepisać, jest równie ważne, jak w jaki sposób . Bez odpowiedniej dyscypliny pisarz techniczny może zapisać zbyt wiele informacji. Ewentualnie mogą przyjąć założenia, które powodują, że pomijają istotne punkty. Po utworzeniu dokumentacja techniczna musi być skrupulatnie aktualizowana, co jest trudną propozycją dla wielu organizacji, które tracą kontrolę nad dokumentami niemal natychmiast po ich napisaniu. Z powodu tych trudności wiedza techniczna rzadko jest przekazywana w samych dokumentach, ale także w parach lub innych formach bliskiej interakcji międzyludzkiej.

Entropia oprogramowania robi ogromne postępy za każdym razem, gdy aktywny uczestnik opuszcza zespół programistów. Zabierają ze sobą cenną wiedzę. Powielanie tego know-how jest niemożliwe, a przybliżenie go wymaga znacznego wysiłku. Jednak przy wystarczającej uwadze i zasobach można zachować wystarczającą wiedzę, aby można było zminimalizować wzrost entropii systemu.

Istnieją inne źródła entropii, ale są one stosunkowo niewielkie. Na przykład gnicie oprogramowania to proces, w którym system jest nieoczekiwanie dotknięty zmianami w jego środowisku. Możemy pomyśleć o oprogramowaniu firm trzecich, na którym się opiera (takim jak biblioteki), ale istnieją inne, bardziej podstępne przyczyny gnicia oprogramowania, zwykle wynikające ze zmian w założeniach, na których opierał się system. Na przykład, jeśli system został zaprojektowany z pewnymi założeniami dotyczącymi dostępności pamięci, może zacząć działać nieprawidłowo w nieoczekiwanych momentach, jeśli dostępna dla niego pamięć zostanie zmniejszona.

Jak obliczyć entropię: przypisywanie wartości do C, S i I

I to liczba nierozwiązanych problemów behawioralnych w systemie oprogramowania, w tym brak obiecanych funkcji. Jest to znana wielkość, która jest często śledzona w systemie takim jak JIRA. Wartość ja wywodzi się z niej bezpośrednio. I to liczba „jednostek pracy”, które zostały porzucone lub pozostawione niekompletne podczas ostatniej iteracji rozwoju, oprócz liczby jednostek pracy wynikających z nowo wprowadzonych i nieoczekiwanych problemów behawioralnych. Ponieważ I jest liczone jako liczba jednostek pracy, możemy powiązać ją z wartością S, która jest zakresem kolejnej iteracji rozwoju w tych samych jednostkach pracy. To, co dokładnie obejmuje „jednostkę pracy”, zależy od metodologii rozwoju.

C jest postrzeganym prawdopodobieństwem, że po wdrożeniu jednostek pracy objętych zakresem liczba faktycznie otwartych problemów I1 w następnej iteracji będzie większa niż obecnie szacuje się. Ta wartość żyje w domenie 0 <= C <= 1.

Można argumentować, że prawdopodobieństwo C jest dokładnie tym, co ma mierzyć entropia oprogramowania. Istnieją jednak zasadnicze różnice między tą wartością a naszą miarą entropii oprogramowania. Postrzegane prawdopodobieństwo, że coś pójdzie nie tak, jest dokładnie takie: nie jest to rzeczywista wartość. Jest to jednak przydatne, ponieważ uczucia osób biorących udział w projekcie są cennym źródłem informacji o jego stabilności.

Zakres S uwzględnia wielkość proponowanych zmian i musi być wyrażony w tych samych jednostkach co I. Większa wartość S zmniejsza entropię, ponieważ zwiększamy zakres proponowanych zmian. Chociaż może to brzmieć sprzecznie z intuicją, musimy pamiętać, że entropia jest miarą tego, jak rozwój systemu może nie spełniać naszych oczekiwań. Nie wystarczy powiedzieć, że entropia jest miarą szansy na wprowadzenie problemów. Naturalnie staramy się przewidywać zagrożenia i uwzględniać je w naszym planowaniu (a zatem w naszych szacunkach I1, które może wzrosnąć powyżej ₀ ). Oczywiście, im bardziej jesteśmy pewni, że podejmiemy się dużego zakresu zmian, tym mniej entropii można powiedzieć o systemie – chyba że ci, którzy planują zmiany i/lub je przeprowadzają, są niekompetentni. Ta możliwość jest jednak prawdopodobnie odzwierciedlona w aktualnej wartości I .

Zauważ, że nie musimy próbować określać wielkości różnicy między rzeczywistą wartością I ₁ a jej wartością oczekiwaną. Jeśli przyjmiemy, że nasze plany są prawidłowe, kiedy je tworzymy, nie jest również rozsądne zakładanie, że możemy przewidzieć stopień, w jakim wynik nie spełni naszych oczekiwań; możemy określić tylko postrzeganą szansę C, że tak się nie stanie. Jednak stopień, w jakim wartość rzeczywista I ₁ różni się od jej wartości oczekiwanej, stanowi istotny wkład do obliczenia entropii w kolejnej iteracji w postaci wartości pochodnej I .

Teoretycznie możliwe jest, że I będzie mieć wartość ujemną. W praktyce jednak taka sytuacja nigdy nie wystąpi; zwykle nie rozwiązujemy problemów przypadkowo. Negatywne wartości nie są dla mnie pocieszającym znakiem. Sugerują, że środki, za pomocą których oblicza się entropię, są wadliwe. Wzrost entropii oprogramowania można oczywiście zredukować, podejmując określone środki, jak opisano poniżej. Jednak w takich przypadkach nie powinienem przyjmować wartości negatywnych, ponieważ zawsze uwzględniamy nasze oczekiwania w naszych projektach.

C jest wartością subiektywną. Istnieje w umysłach uczestników iteracji rozwoju i można ją wywnioskować, przeprowadzając ankietę i uśredniając wyniki. Pytanie należy zadać w pozytywny sposób. Na przykład: „W skali od 0 do 10 z prawdopodobieństwem 10, jak oszacowalibyście szanse zespołu na osiągnięcie wszystkich celów w tej iteracji rozwoju?”

Zauważ, że pytanie dotyczy celów zespołu jako całości, a nie podzbioru. Odpowiedź 10 wskazywałaby wartość 0 dla C, podczas gdy odpowiedź 7 wskazywałaby wartość 0,3. W większych zespołach każda odpowiedź może być ważona w zależności od odpowiednich czynników, takich jak czas, w którym dana osoba jest zaangażowana w projekt i ile czasu faktycznie na to poświęca. Kompetencje nie powinny być jednak czynnikiem ważenia odpowiedzi. Już niedługo nawet młodszy członek zespołu będzie miał poczucie, jak skutecznie osiąga swoje cele. Wystarczająco duże zespoły mogą chcieć odrzucić najwyższe i najniższe zgłoszone wartości przed uśrednieniem pozostałych.

Pytanie profesjonalistów o prawdopodobieństwo porażki ich zespołu jest delikatną i prowokacyjną propozycją. Jednak jest to dokładnie pytanie, które musi zadać każda organizacja, która chce określić ilościowo entropię. Aby zapewnić uczciwe odpowiedzi, uczestnicy powinni podać swoją ocenę C anonimowo i bez obawy przed reperkusjami, nawet jeśli zgłaszają wyjątkowo wysoką wartość.

S musi mieć przypisaną wartość w tych samych „jednostkach pracy” co ja, a zatem jest silnie uzależnione od metodologii rozwoju. W przypadku zespołów, które wykorzystują aspekty metodologii Agile, historie wydają się najbardziej oczywistą „jednostką pracy” zarówno dla S, jak i dla mnie . W takim przypadku zakres iteracji rozwoju obejmuje każde regularnie zaplanowane wydanie do produkcji, zarówno drobne, jak i główne. Powinienem być określony ilościowo jako suma liczby historii, które nie zostały pomyślnie ukończone podczas każdego sprintu poprzedzającego wydanie, oraz liczby historii wygenerowanych do włączenia do przyszłych sprintów w wyniku nieoczekiwanych problemów pojawiających się po wydaniu.

Należy zauważyć, że nie uważamy poprawek lub innych nieplanowanych wydań do produkcji jako definiujących zakres iteracji rozwoju, ani nie powinniśmy odejmować żadnych powiązanych historii od I .

Trudność w tym podejściu polega na tym, że zanim błędy zostaną podzielone na historie, musi nastąpić okres odkrywania i analizy. Prawdziwą wartość I można zatem określić dopiero po opóźnieniu. Ponadto odpytywanie na C występuje naturalnie na początku każdego sprintu. Uzyskane wyniki należy zatem ponownie uśrednić w całym okresie uwalniania. Pomimo tych trudności, każdy zespół stosujący aspekty metodologii Agile prawdopodobnie stwierdzi, że historie są najdokładniejszą jednostką do ilościowego określenia S (a zatem I ).

Obecnie stosowane są inne metodologie rozwoju. Bez względu na zastosowaną metodologię, zasady pomiaru entropii oprogramowania pozostają takie same: entropia oprogramowania powinna być mierzona między wydaniami do produkcji, S i I powinny być mierzone w tych samych „jednostkach pracy”, a szacunki C powinny być pobierane od bezpośrednich uczestników w sposób niezagrażający i najlepiej anonimowy.

Zmniejszenie wzrostu E

Gdy wiedza o systemie zostanie utracona, nigdy nie można jej odzyskać. Z tego powodu entropia oprogramowania nie może zostać zmniejszona. Jedyne, na co możemy mieć nadzieję, to powstrzymanie jego wzrostu.

Wzrost entropii można ograniczyć, stosując odpowiednie środki podczas tworzenia oprogramowania. Aspekt programowania parami w rozwoju Agile jest szczególnie przydatny w tym zakresie. Ponieważ w czasie pisania kodu zaangażowanych jest więcej niż jeden programista, wiedza o istotnych szczegółach jest rozpowszechniana, a skutki odchodzących członków zespołu są łagodzone.

Inną przydatną praktyką jest tworzenie dobrze zorganizowanej i łatwej do wykorzystania dokumentacji, zwłaszcza w organizacjach stosujących metodologię kaskadową. Taka dokumentacja musi być poparta ścisłymi i dobrze zdefiniowanymi zasadami zrozumiałymi dla wszystkich. Do tego podejścia dobrze nadają się organizacje, które opierają się na dokumentacji jako podstawowym środku komunikacji i ochronie wiedzy technicznej. Dopiero gdy nie ma wytycznych ani szkoleń na temat pisania i używania dokumentów pisanych wewnętrznie – jak to często ma miejsce w młodszych organizacjach stosujących metodologie RAD lub Agile – ich wartość staje się podejrzana.

Istnieją dwa sposoby na zmniejszenie wzrostu entropii w systemie: wykonanie zmian mających na celu zmniejszenie I lub wykonanie zmian mających na celu zmniejszenie C.

Pierwsza obejmuje refaktoryzację. Działania mające na celu zmniejszenie I mają zwykle charakter techniczny i prawdopodobnie są już znane czytelnikowi. Musi nastąpić iteracja rozwoju. Część tej iteracji, która ma na celu ograniczenie wzrostu entropii , nie przyniesie żadnych wymiernych korzyści biznesowych, a jednocześnie pochłonie czas i zasoby. Fakt ten często sprawia, że ​​ograniczenie wzrostu entropii jest trudne do sprzedania w każdej organizacji.

Zmniejszenie wartości C jest skuteczniejszą strategią, ponieważ efekt jest długoterminowy. Ponadto C działa jako ważny element kontrolny wzrostu stosunku I do S. Działania mające na celu zmniejszenie C zwykle koncentrują się na ludzkim zachowaniu i myśleniu. Chociaż działania te same w sobie mogą nie wymagać iteracji programistycznej, spowalniają kolejne iteracje, ponieważ uczestnicy akceptują i dostosowują się do nowych procedur. Pozornie prosty akt uzgadniania, jakie ulepszenia należy wprowadzić, jest ścieżką samo w sobie pełną niebezpieczeństw, ponieważ nagle wychodzą na jaw odmienne cele uczestników projektu i interesariuszy.

Zawijanie

Entropia oprogramowania to ryzyko, że zmiana istniejącego oprogramowania spowoduje nieoczekiwane problemy, niespełnione cele lub jedno i drugie.

Chociaż nieistotne, gdy oprogramowanie jest tworzone po raz pierwszy, entropia oprogramowania rośnie z każdą iteracją rozwoju. Jeśli pozwolimy na kontynuowanie działań bez kontroli, entropia oprogramowania ostatecznie zatrzyma dalszy rozwój.

Jednak nie każdy projekt powinien liczyć się ze skutkami entropii oprogramowania. Wiele systemów zostanie wycofanych z produkcji, zanim entropia wywrze zauważalne i szkodliwe skutki. Dla tych, których żywotność jest wystarczająco długa, że ​​entropia stanowi wiarygodne ryzyko, uświadomienie sobie jej i mierzenie jej zasięgu, chociaż wciąż jest niskie, zapewnia środki zapewniające, że rozwój nie zostanie przedwcześnie przerwany.

Gdy system zostanie całkowicie przytłoczony skutkami entropii oprogramowania, nie można już wprowadzać żadnych zmian, a rozwój zasadniczo dobiegł końca.