Błąd nr 9: Zbytnie otwarcie na użytkownika

Programiści lubią mieć dostęp do zmiennych i zmieniać różne rzeczy w kodzie programu, ale większość użytkowników nie ma o tym pojęcia. W systemie Android podczas instalacji aplikacji mogą pojawiać się pytania o sposób, w jaki program uzyskuje dostęp do moich danych. To oczywiste, że zespół Androida stworzył wspaniale precyzyjny zestaw opcji, dzięki którym można zdecydować o zezwoleniach dla oprogramowania w zależności od tego, czy używa aparatu fotograficznego, GPS czy tuzina innych możliwości. Obciążanie użytkowników decyzjami o rzeczach, które nie w pełni rozumieją, jest jednak błędem, może skutkować lukami w bezpieczeństwie i prywatności. Ironia polega na tym, że choć większość użytkowników ma obsesję na punkcie możliwości kupowanego towaru, to nie potrafią sobie oni poradzić z całą gamą funkcji dostępnych w danym programie.

Błąd nr 10: Nadmierne zacieśnianie możliwości użytkownika

Niektórzy programiści postanawiają uniknąć kłopotu z nadmiarem funkcji przez oferowanie dokładnie jednego rozwiązania. Na przykład Gmail słynął z posiadania zaledwie kilku opcji, ulubionych przez programistów. Nie było katalogów, ale można oznaczyć e-maile’a tagami, co programiści uważają za jeszcze silniejsze narzędzie niż katalogi. Jeśli jednak użytkownikom nie spodoba się pomysł, będą szukali obejścia ograniczeń - co przełoży się na osłabienie bezpieczeństwa lub powstanie niechcianej konkurencji. Poszukiwanie złotego środka pomiędzy bogactwem funkcji i prostotą jest wyzwaniem, często bardzo kosztownym.

Błąd nr 11: Zamykanie źródeł

Jednym z najtrudniejszych wyzwań stojących przed każdą firmą jest określenie, jak dużo udostępnić tym, którzy używają oprogramowania.

John Gilmore, współzałożyciel Cygnus Solutions, mówi, że decyzja o nieudostępnianiu kodu działa na szkodę jakości tego kodu, zamyka drogę do innowacji, a co ważniejsze, do odkrywania i usuwania błędów.

"Praktycznym skutkiem otwarcia kodu są poprawki pochodzące od ludzi, o których nigdy nawet nie słyszałeś" - mówi Gilmore. "Będą znajdować błędy, spróbują je poprawić, będą dodawać funkcje, będą rozbudowywać dokumentację. Nawet jeśli ich poprawki będą amatorskie, to kilka minut namysłu pozwoli odkryć bardziej profesjonalny sposób uzyskania podobnych wyników".

Sam kod staje się bardziej modularny i nabiera lepszej struktury, kiedy różni ludzie rekompilują program i przenoszą na inne platformy. Otwarcie kodu zmusza do udostępnienia informacji, poprawy zrozumiałości i jakości kodu.

Błąd nr 12: Zakładanie, że otwartość to lek na wszystko

Miliony projektów open source zostało rozpoczętych, ale tylko niewielki odsetek zdołał przyciągnąć większe grono osób. O ile otwartość umożliwia włączenie się i ulepszanie kodu, o tyle sam fakt otwartości nie przyda się na wiele, jeśli nie ma innych bodźców dla włożenia pracy przez ludzi z zewnątrz. Otwartość nie zapobiegnie błędom bezpieczeństwa, nie zlikwiduje zawieszania się programu ani nie uczyni góry niedokończonego kodu naprawdę użytecznym.

Otwarcie projektu może również stworzyć dodatkowy narzut na komunikację i dokumentację. Zamknięty projekt wymaga solidnej dokumentacji dla użytkowników, ale dobry projekt otwarty zawiera rozległą dokumentację API i plany rozwoju. To się opłaca w dużych projektach, ale może przeciążyć małe. Z kolei otwarcie niektórych projektów może również zamknąć źródła finansowania i spowodować rządy tłumu.

Na podstawie: 12 programming mistakes to avoid by Peter Wayner, Computerworld, December 6, 2010.