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

9

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.

Evan
źródło
1
spójrz na EXXXXXXXXXXXXXXXXXTREEEEEEEEEEEEEMEE Programowanie ...
crasic
Nie ma „pomysłów mas”, tylko pomysły, które stają się popularne, i nie sądzę, aby jakikolwiek pomysł, jak zrobić coś, co jest w użyciu wystarczająco długo, aby stać się popularnym, może być „po prostu zły”, ponieważ to oczywiście musi rozwiązać niektóre problemy, w przeciwnym razie zostanie natychmiast porzucony przez wszystkich, którzy spróbują.
Michael Borgwardt,
2
CORBA nie jest awarią .. wciąż jest w użyciu
oenone
@oenone, jest to porażka w tym sensie, że nie spełniła swojej pierwotnej obietnicy rozwiązania problemów związanych z interoperacyjnością w ogóle, a teraz jest technologią niszową.
Péter Török,
HTTP JSON rozwiązał problemy z WebServices, ale tak naprawdę nie z innym obszarem oprogramowania!
sarat

Odpowiedzi:

11

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?

Péter Török
źródło
Czytając ten link: drogi Boże, CORBA musiał być okropny, gdyby EJB V1 zastąpili go, ponieważ były prostsze ...
Michael Borgwardt
Opracowany przez Michi Henning produkt naprawia wiele braków CORBA.
Blrfl,
13

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” .

Model wodospadu Winstona Royce'a

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.

Thomas Owens
źródło
6
Ludzie wybrali pierwszą metodę Wodospadu, ponieważ byłoby to uderzająco podobne do projektu inżynierii lądowej, takiego jak budowa 40-piętrowego wieżowca. Podczas budowy wieżowca wymagania i ograniczenia są zbyt boleśnie jasne, aby je przeoczyć, i nic ważnego nie zmieni się w połowie. Analiza i projekt (architektura) muszą być kompletne i dokładne, nie pozostawiając miejsca na interpretację. Budynek musi zostać zbudowany zgodnie ze specyfikacją, a na koniec inspektorzy muszą wejść i zakwalifikować gotowy produkt. Oprogramowanie prawie nigdy nie jest tak jasne, dlatego model Waterfall jest awarią.
wałek klonowy
2
@maple_shaft Uważam to za interesujące, ponieważ Winston Royce był pierwszą osobą, która omawiała użycie tego modelu w projekcie oprogramowania i stworzyła schemat, który jest dziś znany wszystkim, ale ludzie nie czytali dalej, aby zobaczyć, dlaczego powiedział, że nie powinien być używane w projekcie oprogramowania. Jeśli osoba, która jako pierwsza napisała ten pomysł, stwierdzi, że jest zły i nie tylko wyjaśni, dlaczego, ale jak zrobić to dobrze, dlaczego ludzie zdecydowaliby się go zatrzymać? Zastanawiam się, czy ma to związek z pierwszymi inżynierami oprogramowania pochodzącymi z matematyki i elektrotechniki. Czy w EE to podejście działa?
Thomas Owens
1
Model wodospadu nie jest całkowicie błędny: poprawnie identyfikuje ogólne fazy tworzenia projektu oprogramowania i porządkuje je logicznie. To, czego nie uznaje, to fakt, że projekt oprogramowania może być napisany iteracyjnie i modułowo, i jako takie kroki opisywane przez model kaskadowy mogą być wykonywane w różnych konfiguracjach dla poszczególnych iteracji i / lub komponentów całego systemu.
tdammers,
3
@Thomas Owens: „Jeśli osoba, która jako pierwsza napisała ten pomysł, twierdzi, że jest zły i nie tylko podaje, dlaczego, ale jak zrobić to dobrze, dlaczego ludzie i tak mieliby się do niego przyczepić?” Adam Smith, ojciec nowoczesnego kapitalizmu, napisał swój manifest na wolnym i czystym rynku, ale później w swojej książce mówi dalej o tym, jak niebezpieczne może być pojęcie korporacji i jak podważają rządy, aby wpływały na rynki na ich korzyść. Dogodnie ludzie ignorują te części pojęcia, których albo nie rozumieją, albo są sprzeczne z wcześniejszymi wyobrażeniami o tym, co jest prawidłowe.
wałek klonowy
2
„Nie wiem, dlaczego ludzie złapali się pierwszego wodospadu. Chyba lubią podejmować ryzyko i zapraszać do porażki”. IMHO jest dokładnie odwrotnie. Ludzie w ogólności lubią mieć poczucie, że kontrolują sytuację, a diagramy procesów i skomplikowane metodologie dają im poczucie bezpieczeństwa. Ponieważ te procesy i wykresy pomogły im wcześniej w wielu innych obszarach, zakładają (w tym przypadku niesłusznie), że zadziała to w ten sam sposób również w rozwoju SW ...
Péter Török
4

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ą.

Gilbert Le Blanc
źródło
1
Ponadto SQL i Visual Basic, oba zostały zareklamowane, aby umożliwić programistom pisanie programów.
Sean McMillan
2

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

Sean McMillan
źródło
3
Metody formalne to coś więcej niż tylko dowody. Rozciąga się od silnie matematycznych i wykorzystujących dowody twierdzeń, o których wspominasz, do lekkich metod, które obejmują modelowanie przy użyciu UML i OCL i tworzenie formalnej specyfikacji w Z. Tak, wprowadzenie dowolnego poziomu metod formalnych zwiększa czas i koszty, ale jeśli budujesz oprogramowanie, które może zabijać lub ranić ludzi (od rozrusznika serca, samolotu po pocisk), poświęcenie dodatkowego czasu i wysiłku na weryfikację i walidację w jak największym stopniu może oznaczać różnicę między życiem a śmiercią.
Thomas Owens
@Thomas: Dobra uwaga. Metody formalne mają pewne zastosowanie w projektach, w których śmierć jest zagrożona. Ale z pewnością nie były srebrną kulą dla oprogramowania wolnego od błędów.
Sean McMillan,
Absolutnie. Mają swoje miejsce w oprogramowaniu o kluczowym znaczeniu dla misji i życia, w różnym stopniu w zależności od systemu. W końcu nie ma srebrnych kul.
Thomas Owens