On May 18, 5:05 pm, Michal Kleczek <k...@g...com> wrote:
> Andrzej Jarzabek wrote:
>
> >> To tylko potwierdza moja teze - jezeli daje sie w dwa miesiace zrobic
> >> _uzyteczne_ (w sensie gotowe do wdrozenia produkcyjnego) oprogramowanie,
> >> to oznacza tylko tyle, ze to oprogramowanie jest po prostu trywialne.
>
> > Można to też ująć w ten sposób, że prawie zawsze złożone
> > oprogramowanie ma w sobie "trywialny" ale już użyteczny, choćby w
> > minimalnym stopniu, rdzeń.
>
> Dajmy na to taki RDBMS albo OS - jaki jest ten trywialny ale juz uzyteczny
> rdzen, ktory daje sie zrobic w dwa miesiace w wersji nadajacej sie do
> produkcji?

Wziąłeś dwa ogólne przykłady typów programów, które mają od dziesiątek
lat wielu przedstawicieli gotowych do kupienia lub wzięcia z półki.
Oczywiście istnieje użyteczny rdzeń RDBMS czy OS jako takiego.
Przykładowo dla RDBMS będzie to program, który trzyma n tablic, gdzie
każda tablica ma k kolumn, dane są persistent i istnieje dostęp do
nich w jakikolwiek sposób, plus jakieś indeksy. Program, który spełnia
te założenia można napisać nawet w miesiąc i on już może być do czegoś
użyteczny. Oczywiście tu i teraz, gdzie istnieją gotowe RDBMSy można
powiedzieć, że skoro mozna mieć znacznie bardziej użyteczne RDBMSy za
darmo, to użyteczność robionego na zamówienie RDBMSa o takiej
funkcjonalności jest w praktyce zerowa.

Ale w takim razie jeśli pytamy o robienie nowego RDBMSa na zamówienie
tu i teraz, to powstaje pytanie, dlaczego ktoś w ogóle zamawia nowego
RDBMSa? Odpowiedź może brzmieć np. tak, że potrzebny jest mu killer
feature A, którego nie ma żaden dostępny na rynku RDBMS. I w takiej
sytuacji dla klienta może być nawet użyteczny minimalny RDBMS z killer
feature A, choćby nie miał języka zapytań, dostępu przez sieć,
transakcji, równoległego dostępu, większości rodzajów constraint'ów,
wymagał wyłączenia bazy w celu zmiany schematu itd.

Jeśli wydaje ci się, że to abstrakcyjny przykład, to ja sam pracowałem
w całkiem sporej i nieźle dochodowej firmie, która sobie wewnętrznie
zrobiła i od kilkunastu lat intensywnie eksploatowała system bazy
danych odpowiadający mniej więcej temu, co opisałem powyżej - w
zasadzie wszystkie produkty tej firmy opierały się na tym RDBMSie. A
to był zestaw ficzerów po długotrwałym rozwoju, z poprawką tylko na
to, że była mocno ograniczona forma równoległego dostępu. Nie tak
dawno przed tym, jak zacząłem pracowac w tej firmie dodano rewolucyjną
możliwość dynamicznego resizowania tablic: wcześniej w konfiguracji
się określało, ile dana tablica ma maksymalnie rekodrów, i tyle ona
zajmowała miejsca zawsze, a jak się próbowało dodać więcej, to był
fail.

> Nawet - przykladowo - glupi programik do wypelniania PIT nie ma takiego
> "rdzenia", bo - mimo ze koncepcyjnie prosty - nadaje sie do sprzedazy
> dopiero jak jest dopracowany w szczegolach (co zajmuje czas) - inaczej firma
> moze stracic tzw "dobre imie" co sie przeklada na przyszle przychody.

Na szczęście nie wypełniam PIT, więc nie mam na ten temat nic do
powiedzenia :)

> > Oczywiście cel posiadania wersji gotowej do releasowania w ciągu dwóch
> > miesięcy nie jest taki, żeby po dwóch miesiącach produkt wypuścić do
> > produkcji, tylko żeby od tego momentu być gotowym do zrobienia release
> > w dowolnym momencie.
>
> Niespecjalnie widze roznice (chyba ze "zrobienie release" jest czyms innym
> niz "wypuszczenie do produkcji" - jezeli tak, to tylko przesuwamy problem).

Release to jest to samo, co wypuścić do produkcji. Gotowy do release
to nie to samo, co zrobić release. Widzisz już różnicę?