Jaki jest dobry przykład pomysłu lub techniki tworzenia oprogramowania, która była porażką?

W szczególności jakie są niektóre przykłady, w których idee mas są po prostu błędne. Dlaczego ludzie wpadli na pomysły w pierwszej kolejności? I dlaczego pomysły zostały odrzucone? A może pomysły wciąż żyją i mają się dobrze, a jeśli tak, to dlaczego?

Na przykład mogę opisać CORBA (i inne podobne technologie) jako coś, co próbowało rozwiązać problem komunikacji między komponentami oprogramowania. Wielu uważa, że ​​konieczne jest zdefiniowanie umów między różnymi komponentami. Ostatecznie HTTP + JSON rozwiązał problem mas i pojawiły się inne mechanizmy RPC, takie jak Thrift i Proto-bufs.

Zasadniczo, podobnie jak w świecie poza komputerami, pomysły i technologie rywalizują o uwagę, dźwignię itp. Niektóre wygrywają, inne przegrywają; a niektórzy mogą wydawać się Zwycięzcami przez jakiś czas, a potem znikną w zapomnieniu wraz z nadejściem Następnej wielkiej rzeczy. Może, ale nie musi mieć nic wspólnego z tym, co było lepsze. Świadek VHS vs Betamax, lub nowszej wojny między różnymi formatami DVD.

CORBA była ogromna, niewygodna i trudna w użyciu, ale była to najlepsza rzecz, jaką niektórzy ludzie mogli wymyślić w tym czasie (zauważ, że została ona zaprojektowana zanim World Wide Web - i HTTP, Java, XML ... - stały się powszechnie znane). Był to również klasyczny przykład projektu opracowanego przez komisję , w którym wtrącają się w każdy pomysł, aby zadowolić wszystkich, ostatecznie czyniąc go bezużytecznym wzdęciem (przynajmniej oglądanym przez dzisiejsze oczy). Nie wspominając już o jego cenie, która wraz z pojawieniem się FOSS wkrótce stała się wygórowana.

Ostatecznie HTTP + JSON rozwiązał problem dla mas

Przynajmniej dla kogoś, kto nie widział, aby kilka podobnych „ostatecznych rozwiązań” wzrosło i ostatecznie upadło ... Warto pamiętać, że w tamtym czasie podobna była opinia na temat CORBA ;-)

Czuję, że warto cytować z The Rise and Fall of CORBA :

Historia CORBA jest historią, którą przemysł komputerowy widział wiele razy i wydaje się prawdopodobne, że obecne wysiłki w zakresie oprogramowania pośredniego, w szczególności usług sieciowych, odtworzą podobną historię. [...]

Ogólnie rzecz biorąc, proces wdrażania technologii OMG musi być postrzegany jako główny powód upadku CORBA. Proces zachęca do projektowania przez komisje i manewrów politycznych do tego stopnia, że ​​trudno jest osiągnąć przeciętność techniczną, nie mówiąc już o doskonałości technicznej. Ponadto dodanie rozłącznych elementów prowadzi do stopniowej erozji wizji architektonicznej. [...]

Proces demokratyczny, taki jak OMG, jest wyjątkowo nieodpowiedni do tworzenia dobrego oprogramowania. Jednak pomimo znanych problemów proceduralnych branża woli polegać na dużych konsorcjach w zakresie produkcji technologii. Usługi sieciowe, obecnie srebrna kula oprogramowania pośredniego, wykorzystują proces bardzo podobny do OMG i, według wielu kont, cierpią również z powodu konfliktów, fragmentacji, braku spójności architektonicznej, projektowania przez komitet i wzdęcia. Wydaje się nieuniknione, że usługi sieciowe wprowadzą historię podobną do historii CORBA.

Teraz z innej perspektywy: czytając twój termin „idee mas”, pomyślałem o czymś zupełnie innym niż CORBA lub inne standardy; są to zazwyczaj pomysły jednej osoby lub małej grupy. Myślałem o znanych praktykach / punktach widzenia, takich jak „kodowanie kowboja”, „kodowanie i modlitwa”, „działa na mojej maszynie” itp. To są prawdziwe „pomysły mas” IMHO, ponieważ jest to sposób, w jaki prawie każdy początkujący deweloper instynktownie zaczyna pisać kod. I są w błędzie, ponieważ nie skalują się ani w przestrzeni, ani w czasie - nie można w ten sposób tworzyć dużych, łatwych do utrzymania, rozszerzalnych programów. Jednak uważam, że niestety nadal jest to normą, a nie wyjątkiem, że ludzie próbują pracować w ten sposób w profesjonalnych sklepach na całym świecie.

Inną skrajnością tego są pomysły wielu menedżerów i teoretyków na temat „właściwego podejścia” do rozwoju SW, przejawiające się w dużych metodologiach, takich jak CMM, RUP, Waterfall itp. Ideą leżącą u ich podstaw jest to, że wszystko czego potrzebujesz to właściwy proces, a on zacznie automatycznie wytwarzać wysokiej jakości oprogramowanie w deterministyczny sposób, niezależnie od tego, kim naprawdę są programiści. Zauważ, że w tę samą grę można również grać metodami zwinnymi - to tylko zmiana etykiet. Każdy menedżer, który uważa, że ​​wybór (i utrzymanie) odpowiednich członków do swojego zespołu programistycznego jest mniej ważny niż proces programistyczny, jest skazany na porażkę, w zależności od tego, który proces się zdarzy. Jednak ta wiara w proces nadal wydaje się dominująca - może nadal jest nauczana w szkołach zarządzania?

Częstym przykładem osób, które popełniły błąd, jest model wodospadu. Jest to schemat stereotypowego modelu wodospadu, który pojawia się również w pracy Winstona Royce'a „Zarządzanie rozwojem dużych systemów oprogramowania” .

Po tym obrazie znajduje się ten tekst:

Wierzę w tę koncepcję, ale opisana powyżej implementacja jest ryzykowna i prowadzi do niepowodzenia ... Faza testowania, która ma miejsce pod koniec cyklu rozwoju, jest pierwszym zdarzeniem, dla którego czas, przechowywanie, wejście / wyjście, transfery itp., są doświadczeniami różniącymi się od analizowanych. Zjawiska te nie są dokładnie analizowane. Nie są to na przykład rozwiązania standardowych równań różniczkowych cząstkowych fizyki matematycznej. Jeśli jednak zjawiska te nie spełniają różnych ograniczeń zewnętrznych, niezmiennie konieczna jest znaczna przeprojektowanie. Prosta ośmiokrotna łatka lub ponowienie izolowanego kodu nie naprawi tego rodzaju trudności. Wymagane zmiany w projekcie prawdopodobnie będą tak destrukcyjne, że zostaną naruszone wymagania oprogramowania, na których opiera się projekt i które uzasadniają wszystko. Albo wymagania muszą zostać zmodyfikowane, albo wymagana jest istotna zmiana w projekcie. W efekcie proces rozwoju powrócił do źródła i można oczekiwać nawet 100-procentowego przekroczenia harmonogramu i / lub kosztów.

W dalszej części artykułu Royce przedstawia alternatywne modele procesów, które polegają na iteracji między fazą bieżącą i fazą poprzednią oraz cyklem między analizą wymagań i projektem a innym cyklem między testem kodu projektu. Identyfikuje również szereg dokumentów, na których etapach należy je ukończyć, i opowiada się za zaangażowaniem klienta i licznymi wodospadami na każdej fazie, w tym analizą, testowaniem i wykorzystaniem wszystkich zaangażowanych artefaktów. W gruncie rzeczy to, co Royce omawia, można uznać za wczesne podejście do metod zwinnych - wciąż jednak w dużej mierze oparte na planach, ale stanowiące podstawę zwinnego ruchu.

Dlaczego ludzie złapali się pierwszego wodospadu, nie wiem. Chyba lubią podejmować ryzyko i zapraszać do porażki.

Automatyczne generowanie kodu z wyższego poziomu abstrakcji lub automatyczne programowanie .

W artykule w Wikipedii brakuje nieco informacji historycznych, ale było to marzenie menedżerów, odkąd programiści stali się drożsi niż komputery.

Po opracowaniu języków wyższego poziomu, takich jak Fortran i Cobol, nastąpił rozwój języków specjalnych, takich jak pisanie raportów. Easytrieve i SAS były kilkoma przykładami.

W latach 80. narzędzia CASE były wściekłe. CASE oznacza inżynierię oprogramowania wspomaganą komputerowo. Uważano, że rygorystyczne stosowanie zasad inżynierii przyspieszy rozwój oprogramowania. Głównym powodem, dla którego narzędzia te się nie przyjęły, oprócz kosztów, był wysoki poziom standaryzacji danych wymagany do skutecznego działania narzędzi.

Internet zyskał na znaczeniu w latach 90. Eksplodowały rodzaje programowania ułatwiane przez Internet. Od programistów wymagano posługiwania się ilustracjami, mapami, zdjęciami i innymi obrazami, a także prostą animacją, w tempie niespotykanym wcześniej, przy użyciu kilku dobrze znanych metod. Mnożono liczbę technologii wytwarzania tych obiektów. Zniknęły marzenia o automatycznym programowaniu.

Outsourcing programowania w tańszych lokalizacjach to jedna z niewielu metod redukcji kosztów programisty. Problemy z outsourcingiem obejmują problemy z komunikacją i problemy ze specyfikacją.

Metody formalne

Dawno, dawno temu zaproponowano, że oprogramowanie może być sprawdzone. (Pomysł polega na tym, że testy nie mogą wykazać, że nie ma błędów, ale dowody byłyby w stanie.) Niestety, opracowanie dowodu dla programu ma kilka poważnych wad:

• Jest to trudniejsze i bardziej czasochłonne niż pisanie programu.
• Musi obejmować cały program, co oznacza, że ​​potrzebujesz dowodów dla dowolnej biblioteki, systemu operacyjnego itp.
• Nie świadczy to o braku błędów, ponieważ mogą one być spowodowane przypadkiem.

Ta koncepcja była bardzo popularna w latach 70.

Linkage: http://en.wikipedia.org/wiki/Formal_methods http://c2.com/cgi/wiki?ProofOfCorrectness http://c2.com/cgi/wiki?PractitionersRejectFormalMethods