Tanie i dobre aplikacje internetowe? Niemożliwe

A jednak!

Nie da się zmniejszyć czasu, a co za tym idzie i kosztu wykonania aplikacji internetowej li tylko poprzez pozytywne myślenie i pokrzykiwania, tudzież tak zwaną motywację a'la "Sprężcie się, obiecaliśmy to na dwunastego!"

I cóż z tego? Developer nie cudotwórca, swoją efektywność ma. To prawda, tymczasowo jest w stanie ją zwiększyć, jednakże takowe piki wydajności zdarzać się mogą sporadycznie i na krótko. Ciągłe przeciążanie programisty w dłuższym terminie skutkuje bowiem jednym - porażką projektu.

Jak więc obniżyć koszt budowy aplikacji i zapewnić klientowi nie tylko niższy koszt i czas realizacji, ale jednocześnie wyższą jakość? Odpowiedź jest jedna.

Reusability, durniu!

Z braku dobrego polskiego odpowiednika termin ten wkradł się do naszego środowiska na stałe. Cóż oznacza? Ano nic innego jak "ponowną używalność" lub "wielokrotną używalność". W praktyce sprowadza się to do jednego zdania - nie wynajduj koła ponownie, lecz korzystaj z tego, co już ktoś przed Tobą stworzył.

Prawda, że proste? Otóż nie! Konia z rzędem temu, kto wskaże na naszym rynku te firmy, który rzeczywiście potrafią zastosować się do tej zasady. Naprawdę duże spółki IT, powiecie? Prawda. Ale po pierwsze nie o nich tu mowa, po drugie, cóż... nawet tam nie jest tak różowo jak moglibyśmy podejrzewać.

Przyczyna tego jest prosta i zarazem dosyć kuriozalna - brak czasu.
Dziwne? Niezbyt. Pozwólcie, że przedstawię krótki tok rozumowania naszej hipotetycznej firmy X:

1. otrzymujemy zapytanie ofertowe od klienta,
2. nasi specjaliście szacują koszt czasowy wykonania projektu,
3. handlowcy kręcą nosem, bo szacunki sięgają sufitu. Następuje faza negocjacji podczas której developerzy lżą handlowców, a handlowcy developerów,
4. w ten czy inny sposób, z zapewnieniami na modłę "Ale to tylko wstępny szacunek, potem się go doprecyzuje", docieramy do kompromisu,
5. oferta wysyłana jest do klienta, który - dajmy na to - decyduje się na nasze usługi,
6. szacunki, rzecz oczywista, nigdy się nie zmieniają i do końca pozostają na wstępnym, mocno niepewnym poziomie wartości,
7. projekt rusza,
8. nikt, absolutnie nikt nie ma chęci ani możliwości dołożyć nieco czasu i napisać lepszy, możliwy do wielokrotnego wykorzystania kod, bo terminy gonią, a zwierzchnicy ciągle dopytują "Dlaczego to jeszcze nie działa?",
9. projekt się kończy, a my z naszymi zasobami gotowych funkcjonalności lądujemy niemal dokładnie tam, gdzie zaczęliśmy,
10. "No ale myśmy przecież już to pisali. Dlaczego nie da się tamtego kodu ponownie wykorzystać?"

Śmieszne? Prawda. Tragiczne? Również. Głupie? Zapewne.

Więc dlaczego, na wszystkie świętości, firmy jak jeden mąż popełniają ten sam błąd raz za razem?
Nie mam pojęcia.