Infinitely Extensible Projects

When diving into new language, or radically different framework, it may be a good idea to have a bigger project where you can apply your newfound skills. In my experience, this is typically better than having a lot of smaller ones, because it minimizes the hassle of project’s initial setup. Therefore, it encourages you to experiment more.

To reap the largest benefits of this approach, the project of choice should exhibit two important properties:

• It must be easy to get started. Note that it doesn’t necessarily mean a complete programming newbie should be able to code the initial scaffolding in one session. But getting started must be easy for you specifically, so that you can dabble in interesting stuff almost right away.
  What it means exactly is dependent on your overall coding experience, and also on comparative difficulty of whatever you are trying to learn. For those taking their first steps in programming as a whole, extending their first Hello world program might be appropriate. However, if you are learning your fourth of fifth language you can aim for something a tad more ambitious.
• It should offer practically infinite possibilities of extension. The idea is for the project to grow along with skills and knowledge you acquire, enabling you to try ever more things.
  In normal development, this typically results in feature creep and is best avoided. But experimental, exploratory, educational coding does not really have to be concerned with such notions. Of course, if you can pack your learning experiences into a usable program then double kudos to you.

What types of projects fit into this characteristic? I’d say quite a lot of them.

When I was honing my Python skills, I started programming an IRC bot so that I could cram a few ideas into it rather quickly. They were implemented mostly as commands that users could input and have the bot perform some actions, like searching Wikipedia for any given term.
A similar pattern (collection of mostly independent commands) can be realized in many different scenarios. Aspiring web programmers could come up with something like a YubNub clone (bonus points if it allows users to add their own commands). Complete coding novices would probably have to resort to simple, menu-based programs in terminal instead.

Another option is to attack a problem which is a very broad and/or vague. Text editors, for example, fuel countless discussions (even wars) over what functionality should they contain and how it should be accessible in the UI. Chances are slim that your take on the problem sprouts a new Emacs or Vim, but a home-brewed editor is easy enough to start and obviously extensible, almost without limits. Additionally, editors can fit into pretty much any environment, from terminals to desktop UIs or HTML5 applications.

Some endeavors are a bit more specific, though. In web development, a CMS or blogging engine became something of a timeless classic now. Everyone has written one at some point, and there’s a lot of additional (thought not always useful) functionality that can be added to it. Getting the basics right is also a challenge here, especially from security standpoint.

For mobile app creators, the infamous To-Do list app is an idea exercised ad nauseam. But it’s actually a good playground for toying with various device capabilities (e.g. location-based reminders) or web services (like Google or iCloud calendar).

More?…

I’m pretty sure I’m far from exhausting the list of possibilities here. I cannot really speak for domains I have little-to-no experience with, for example embedded or hardware-oriented programming with equipment such as Arduino.

It should be possible to come up with infinitely extensible projects for almost every environment and platform, though. After all, every program has always one more feature to add ;)

Czas do końca projektu

Oszacowanie czasu potrzebnego do wykonania danego projektu to odwieczny problem inżynierii oprogramowania. Być może w ostatnich latach coś się w tym względzie zmieniło, ale jeśli nie, to wciąż pozostaje aktualna sugestia, że najskuteczniejszym sposobem jest po prostu… zapytanie kogoś kompetentnego :) Najwyraźniej wypracowanie jakichś ścisłych i skutecznych metod oceny nakładu pracy i czasu przy tworzeniu oprogramowania jest wciąż poza naszym zasięgiem i trzeba się uciekać do metod typu – z naciskiem na drzwi.
Sam mam kilka teorii na temat tego, czemu tak jest. Jedną z nich jest postulat, że do różnego rodzaju projektów należy stosować różne modele przewidujące czas ich trwania. Owych rodzajów jest zaś dokładnie trzy i są to bardzo proste kategorie. Wyróżniam mianowicie projekty zbyt proste, odpowiednie i zbyt trudne. Określenia te odnoszą się – jak można się domyślić – do stopnia trudności danego projektu dla zespołu, który go wykonuje. Nie należy jednak traktować ich zbyt dosłownie ;)

I tak przez projekt zbyt prosty rozumiem taki, którego główne wyzwanie (czyli główna funkcjonalność) jest w gruncie rzeczy łatwe do zrozumienia i zaprojektowania, a co za tym idzie także do zakodowania. Spotykając się z takim zadaniem, możemy bez dużego wysiłku wypracować dla niego rozwiązanie, które wystarczy “tylko” zaimplementować.
Paradoksalnie jednak tutaj mogą zacząć się schody. Kiedy główny problem jest już za nami, i to bardzo szybko, motywacja do kontynuowania prac spada. Mimo że zwykle pozostaje jeszcze sporo do zrobienia, nie są to już czynności wymagające dużego wysiłku intelektualnego, więc często mogą być po prostu nudne. Tempo sukcesywnie więc spada w miarę zbliżania się do końca.

Dokładnie odwrotnie jest z kolei w przypadku projektów zbyt trudnych. Gdy główny problem jest tak skomplikowany, że przez długi czas nie wiadomo, jak właściwie się do niego zabrać, postęp prac jest nikły. W pewnym momencie jednak (miejmy nadzieje) przychodzi olśnienie – albo raczej seria mniejszym “eurek” – i od tego momentu wszystko nabiera bardzo dużego przyspieszenia. I nawet po rozwiązaniu głównego problemu nie musi ono wcale zwalnia, lub inaczej: nawet jeśli zwalnia, to efekt ten nie jest łatwo zauważalny w skali czasowej całego przedsięwzięcia.

Trzecia kategoria leży natomiast pośrodku między dwiema powyższymi. Projekt jest odpowiedni, jeśli przez cały czas trwania prezentuje mniej więcej podobny poziom trudności dla zespołu, który go wykonuje. Oznacza to, że jego główny problem daje się rozwiązać systematycznie i sekwencyjnie, nie zaś prawie automatycznie (w przypadku projektów zbyt łatwych) lub tylko za pomocą nagłego odkrycia (jak w przypadku projektów zbyt trudnych).

Tym trzem kategoriom projektów możemy przypisać krzywe określające poziom zaawansowania prac w zależności od czasu. Nietrudno jest zauważyć, że dla przedsięwzięć zbyt łatwych będzie to funkcja logarytmiczna, dla zbyt trudnych – wykładnicza, zaś dla odpowiednich będzie ona zbliżona do linii prostej:

Jeśli umiemy rozpoznać, do której z tych trzech kategorii należy nasz projekt, to niewykluczone, że możemy spróbować uniknąć niektórych pomyłek przy szacowaniu czasu pozostałego do końca projektu. Dla projektów zbyt łatwych można na przykład łatwiej niż zwykle ulec złudzeniu planowania i nie docenić czasu pozostałego do końca prac, kierując się tym, iż na początku “idzie jak z płatka”. Dla zbyt trudnych można natomiast błędnie ekstrapolować początkowe trudności w przyszłość i wnioskować, że projekt będzie trwał całe lata (podczas gdy może trwać miesiące lub… dekady, w zależności od tego, kiedy nastąpi “olśnienie”).

Najważniejszym wnioskiem – jeśli moje przemyślenia są prawdziwe – jest jednak korzyść, jaką daje zapewnienie, by projekt był odpowiedni. Wówczas szansa na wiarygodne oszacowanie pozostałego czasu jest znacznie zwiększona, bo mówimy wtedy o ekstrapolacji funkcji w przybliżeniu liniowej. Żeby jednak móc korzystać z tej pożytecznej cechy, musimy postarać się o odpowiednie dobranie zespołu do zadania… lub odwrotnie :)

Zależności między projektami w Visual Studio

Zdarza się, że pracuje nad złożonym systemem, na który składa się kilka osobnych projektów. IDE znają dobrze takie przypadki i potrafią je obsługiwać – stąd chociażby pojęcie solution (dawniej workspace) w Visual Studio. Dla pojedynczych aplikacji i bibliotek wydaje się ono zbędne, jednak staje się nieodzowne wtedy, gdy nasze projekty zależą od siebie.

Typowa sytuacja to wspólna biblioteka (framework, engine czy co jeszcze kto woli) rozwijana razem z programami, które z niej korzystają. (W najprostszym przypadku to może być po prostu jakaś aplikacja testowa). Wówczas pojawiają się zależności między projektami na etapie ich budowania: wynik szeroko pojętej “kompilacji” jednego jest wejściem do procesu budowania innego. Jeśli nie poświęcimy temu faktowi należytej uwagi, to mogą nas czekać kłopoty. W najlepszym razie jest to konieczność wciskania F7 (Build Solution) więcej niż raz, aż do zbudowania wszystkich projektów. W gorszym – uruchamianie (i debugowanie!) aplikacji korzystającej z nieaktualnej, bo nieprzekompilowanej wersji biblioteki.

Zależności między projektami w procesie budowania da się na szczęście określić. W Visual Studio służy do tego opcja Project Dependencies z menu – a jakże – Project. Możemy w niej określić dla każdego projektu, z jakimi innymi projektami z tego samego solution jest on powiązany, czyli które z nich powinny być już wcześniej od niego zbudowane. Na podstawie tak podanej sieci zależności da się następnie określić właściwą kolejności “kompilacji” dla wszystkich projektów w danym solution. VS oczywiście to czyni, używając do tego zapewne sortowania topologicznego w analogiczny sposób jak dla kompilacji jednego projektu składającego się z wielu plików.

Wartość pomysłów

Podobno w informatyce najcenniejszym zasobem są pomysły. Bo o ile zrealizowanie gotowej idei to praca czysto rzemieślnicza i – przynajmniej teoretycznie – możliwa zawsze do wykonania przy odpowiednim czasie i przy właściwej liczbie osób, to z kolei “wzięcie skądś” pomysłu nie jest taką prostą sprawą. W końcu, jak to ktoś powiedział, pomysły nie rosną przecież na drzewach :)

Tak to zwykle wygląda z rynkowego punktu widzenia. Dlatego bardzo ciekawy jest fakt, że np. na Warsztacie wygląda to – jak się wydaje – zupełnie odwrotnie. Objawem tego jest choćby fakt, że działy z pomysłami i projektami na forum są jednymi z większych i bardziej aktywnych. Jak to możliwe?
Wydaje mi się, że przyczyny są co najmniej dwie. Po pierwsze, na Warsztat trafiają osoby zainteresowane programowaniem gier i przynajmniej część z tych (a w rzeczywistości pewnie całkiem spora część) chcę zająć się tym tematem między innymi dlatego, że mają w głowie pomysł na jakąś grę. Albo na kilka od razu. A że na początkowym etapie nauki nijak nie da się tego zrealizować, owe genialne idee lądują we wspomnianym dziale forum.
Poza tym, nie ma co ukrywać: większość z nich jest w istocie marnej jakości – nawet jeśli litościwie odsiejemy projekty kolejnych MMORPG-ów, jakie dość często się pojawiają :) Oczywiście dla swoich autorów są one zawsze niezwykle innowacyjne i warte zrealizowania, ale nie łudźmy się: tak naprawdę podobne epitety można przypisać tylko ich małemu ułamkowi.

Innymi słowy, jest duża różnica pomiędzy pomysłem a dobrym pomysłem. Tych pierwszych każdy z nas ma pewnie dziesiątki tygodniowo. Nieuchronnie trzeba więc wybierać z nich tylko te najbardziej wartościowe. Do pozostałych najlepiej jest zaaplikować garbage collector :)

Laboratoria kontra projekty

Studia techniczne – a więc także i informatyka – różnią się od innych choćby tym, że tutaj nie obejdzie się bez dużej ilości zadań praktycznych. Brudzenie tablicy pyłem kredowym na wykładach i ćwiczeniach to bowiem za mało – zwłaszcza, jeśli mówimy o uczelniach technicznych, a nie uniwersytetach.
Mamy więc dwa dodatkowe rodzaje zajęć: laboratoryjne i projektowe. Oba mają na celu wykorzystanie zdobytej przez studenta wiedzy w praktyce oraz nabranie pewnej porcji doświadczenia. Cel chwalebny, wykonanie niestety nieco gorsze…

Dotyczy to głównie laboratoriów, które w pewnej formie są według mnie kompletnym nieporozumieniem, jeśli chodzi o większość dziedzin informatyki – zwłaszcza tych związanych bezpośrednio lub pośrednio z programowaniem. Zajęcia takie wyglądają mniej więcej tak: student otrzymuje takie-a-takie zadanie – którym jest zwykle napisanie programu – i do końca zajęć ma się z niego wywiązać, czyli rzeczony program napisać. Potem wyniki jego pracy są oceniane przez prowadzących.
W czym ta formuła jest zła? Ano można jej wytknąć całkiem sporo mankamentów:

• Nieżyciowość. W pracy nikt przecież nie koduje na akord: wiadomo, że z ośmiogodzinnego dnia programista na efektywną pracę przeznacza najwyżej 4 do 5 godzin. Kogo zresztą byłoby stać na to, by każdy projekt rozparcelować na małe kawałki, które potem byłyby pisane przez koderów w ściśle określonych ramach czasowych? To zapewne całkowicie niemożliwe, a co najmniej wysoce nieopłacalne.
• Złe nawyki. Jeśli mamy tylko godzinę lub dwie, by oddać działający kawałek kodu, na bardzo daleki plan schodzą takie kwestie jak jego czytelność, odpowiedni stopień nasycenia komentarzami, elastyczność, możliwość ponownego wykorzystania, i tak dalej. Krótko mówiąc, produkuje się wtedy kod “tylko do zapisu”, zgodnie z zasadą 3Z: Zakodź, Zalicz, Zapomnij :) Nabyte przy okazji przyzwyczajenia do programistycznego niechlujstwa mogą się odbijać czkawką jeszcze przez bardzo długi czas.
• Stres. Takie laboratoria to tak naprawdę nic innego, jak kartkówka wklepywana na klawiaturze. Nie jest to nic przyjemnego i w (zbyt) dużych dawkach prawdopodobnie może nawet skutecznie odstręczyć od kodowania jako takiego.

W przeciwieństwie do laboratoriów, projekty właściwie nie mają wymienionych wyżej wad. Są też na pewno bardziej pouczające, szczególnie wtedy gdy należy je wykonywać w grupach. Zdobyte przy okazji doświadczenie jest z pewnością o wiele cenniejsze, bo obejmuje przecież także organizowanie pracy i planowanie kolejnych jej etapów. Czegoś takiego nie można raczej powiedzieć o zadaniach wykonywanych na szybko na laboratoriach.

O projektach, które umarły

Uczcimy dzisiaj chwilą ciszy pamięć naszych rozpoczętych projektów, które nigdy nie doczekały się ukończenia. Sporo ich było, prawda?… Potrzeba by naprawdę dłuższej chwili żałoby, żeby wspomnieć wszystkie. Tak się bowiem nieprzyjemnie składa, że wiele znaków na niebie i ziemi wskazuje, że prawdziwe jest stwierdzenie, iż:

O ile w grę nie wchodzą silne czynniki zewnętrzne, każdy rozpoczęty projekt ma bardzo duże szanse na to, by nigdy nie doczekać się realizacji.

Takim silnym czynnikiem nie jest jednak presja wynikająca z pracy w zespole. Jest to czynnik jak najbardziej wewnętrzny, a projekty grupowe mają chyba takie same szanse popadania w stagnację i wreszcie w kompletny zastój. Zapewne jedynie sankcje natury edukacyjnej (gdy chodzi np. o tak zwane projekty ‘na zaliczenie’) czy finansowej (kiedy mówimy o komercyjnym wytwarzaniu oprogramowania) są w większości przypadków wystarczającą “zachętą”. A pewnie i nie zawsze…

Zaś w przypadku projektów totalnie amatorskich i całkowicie dobrowolnych powyższe przygnębiające prawo ma, jak sądzę, wielkie prawdopodobieństwo okazać się trafne. Prawie zawsze znajdzie się jakiś powód – czasem istotny, a czasem zupełnie błahy, a często nawet trudny do określenia – żeby wszystko stanęło i przestało się rozwijać. A im dłuższa jest przerwa, tym trudniej kontynuować potem przerwaną pracę. I wreszcie przekraczamy ten punkt krytyczny, czasową granicę, po przejściu której do danego projektu po prostu się nie wraca.

Okropnie to pesymistyczne, więc może teraz spróbujmy się choć trochę pocieszyć. Otóż nawet jeśli większość naszych przedsięwzięć koderskich nie doczekała się przybrania ostatecznego kształtu, to przecież czas włożony w ich rozwój nie był do końca stracony. Prawdopodobnie tylko w taki sposób można poszerzać swoje umiejętności i zyskiwać niezbędną wiedzę – nie tylko o tym, że kończenie projektów jest bardzo, bardzo trudne :)
A ponadto te niedokończone pomysły nie są przecież zakopywane pod ziemią – chyba że znikają w płomieniach formatowanych dysków czy zostają pożarte przez komputerowe robaki. Rozsądni programiści robią jednak kopie zapasowe i pieczołowicie gromadzą takie “odpady”. A nuż bowiem coś się jeszcze przyda? Jakiś fragment, ciekawe rozwiązanie czy nawet kilka linijek, które kiedyś wyprodukowaliśmy i które akurat teraz są nam potrzebne. To prawda, że po dłuższym czasie możemy być już w zupełnie innym miejscu, pisać w zupełnie innym języku programowania i korzystać z całkowicie innych bibliotek czy innych narzędzi. W kodowaniu pewne rzeczy są jednak uniwersalne i czasem pogrzebanie w zarzuconych projektach może okazać się pożyteczne.

Kto wie, może dzięki takiemu recyklingowi uda się powstrzymać wzrost tej góry śmieci…