Co powoduje złą wydajność aplikacji konsumenckich? [Zamknięte]

Mój Comcast DVR potrzebuje co najmniej trzech sekund, aby zareagować na każde naciśnięcie przycisku na pilocie zdalnego sterowania, co sprawia, że ​​proste zadanie oglądania telewizji staje się frustrującą rozrywką przycisków. Mój iPhone zajmuje co najmniej piętnaście sekund, aby wyświetlać wiadomości tekstowe i ulega awarii ¼ razy, gdy próbuję uruchomić aplikację iPoda; samo otrzymanie i przeczytanie wiadomości e-mail często zajmuje znacznie dłużej niż minutę. Nawet navcom w moim samochodzie ma brudne i nie reagujące sterowanie, często połykając kolejne sygnały wejściowe, jeśli dokonam ich w odstępie krótszym niż kilka sekund.

Są to urządzenia stacjonarne dla użytkowników końcowych, dla których użyteczność powinna być najważniejsza, a jednak wszystkie zawodzą przy podstawowym czasie reakcji i opóźnieniu. Ich oprogramowanie jest po prostu zbyt wolne .

Co za tym stoi? Czy to problem techniczny czy społeczny? Kto lub co jest odpowiedzialne?

Czy to dlatego, że wszystkie zostały napisane w zarządzanych, odśmiecanych językach zamiast w natywnym kodzie? Czy to programiści napisali oprogramowanie dla tych urządzeń? We wszystkich tych przypadkach twórcy aplikacji wiedzieli dokładnie, na którą platformę sprzętową są kierowani i jakie są jej możliwości; czy nie wzięli tego pod uwagę? Czy to ten facet, który krąży w kółko powtarzając: „optymalizacja jest źródłem wszelkiego zła”, czy sprowadził ich na manowce? Czy to mentalność „och, to tylko dodatkowe 100 ms” za każdym razem, aż wszystkie milisekundy sumują się w minutach? Czy to moja wina, że ​​kupili te produkty w pierwszej kolejności?

To subiektywne pytanie, bez jednej odpowiedzi, ale często denerwuję się, widząc tak wiele odpowiedzi tutaj, mówiąc: „och, nie martw się szybkością kodu, wydajność nie ma znaczenia”, kiedy wyraźnie w pewnym momencie ma to znaczenie dla użytkownik końcowy, który utknął z powolnym, niereagującym i okropnym doświadczeniem.

Więc w którym momencie coś poszło nie tak z tymi produktami? Co my, programiści, możemy zrobić, aby uniknąć zadawania bólu naszym klientom?

Dobre pytanie. Widzę to codziennie.

Ludzie pracują nad aplikacjami dobrej wielkości. Gdy działają, pojawiają się problemy z wydajnością, podobnie jak błędy. Różnica polega na tym, że błędy są „złe” - krzyczą „znajdź mnie i napraw mnie”. Problemy z wydajnością po prostu siedzą i stają się coraz gorsze. Programiści często myślą: „Cóż, mój kod nie miałby problemu z wydajnością. Raczej zarząd musi kupić mi nowszą / większą / szybszą maszynę”.

Faktem jest, że jeśli programiści okresowo polują na problemy z wydajnością (co w rzeczywistości jest bardzo łatwe ), mogą po prostu je usunąć.

Zamiast tego „stan techniki” to:

1. polegają na aforyzmach takich jak „unikaj przedwczesnej optymalizacji” i hau-haw 90/10.
2. odważnie mów o profilowaniu, a czasem wypróbuj je, często z rozczarowującymi wynikami, jak widać we wszystkich pytaniach SO na ten temat.
3. oprzeć się na starych dobrych domysłach, zamaskowanych jako doświadczenie i wiedza.

Ale tak naprawdę to jest negatywne. Mówiąc pozytywnie, ta metoda działa prawie cały czas i nie może być prostsza. Oto szczegółowy przykład .

To nie jest problem techniczny, to problem z marketingiem i zarządzaniem.

W tym momencie możesz przewracać oczami, ale proszę o wyrozumiałość.

To, co firma sprzedaje, to „produkt”, a ludzie, którzy definiują, co to jest, to „menedżer produktu”. W firmach technicznych bierze to pod uwagę wiele innych osób - eksperci od doświadczeń użytkowników, yadda yadda. Ale ostatecznie menedżerowie produktu są odpowiedzialni za napisanie specyfikacji tego, co użytkownik powinien otrzymać.

Weźmy twój rejestrator Comcast. Idealnie byłoby, gdyby działało to tak:

1. Menedżer produktu pisze w specyfikacji: „Gdy użytkownik naciśnie przycisk na pilocie zdalnego sterowania i znajduje się w odległości 25 stóp od rejestratora, rejestrator musi odpowiedzieć na naciśnięcie w ciągu 250 milisekund”.
2. Pracownicy techniczni tworzą sprzęt, piszą oprogramowanie wbudowane itp.
3. Testerzy kontroli jakości albo potwierdzają, że system spełnia specyfikację, albo odsyłają go do zespołu technicznego w celu naprawy.

Oczywiście wiele rzeczy może się nie udać:

• Menedżer produktu nie umieścił odpowiedzi przycisku w specyfikacji
• Pracownicy QA wykonują przeciętne zadanie testowania pod kątem specyfikacji
• Ktoś wybrał technologie, które nie pozwalają na spełnienie specyfikacji, więc wymaganie zostaje stłumione
• Personel techniczny ma problemy lub ktoś przyspieszył harmonogram, a pewien menedżer mówi: „Zapomnij o responsywności - ukończ tę drugą funkcję”.
• Menedżer produktu nie publikuje wymaganego czasu reakcji, dopóki tak późno w grze, nie można go spełnić przed datą wysyłki
• Kierownictwo postanawia nie poddawać niczego testom kontroli jakości, dopóki tak późne przyspieszenie wolnego kodu zdestabilizuje produkt

Widziałeś tam wszystkich niezdecydowanych programistów? Nie było żadnych.

Nie twierdzę, że nie ponosimy żadnej odpowiedzialności za niską wydajność - często pisanie dobrego, solidnego i wydajnego kodu jest tak samo łatwe i szybkie, jak pisanie śmieci.

Ale tak naprawdę, jeśli kierownictwo produktu i pracownicy kontroli jakości śpią za kierownicą, my, programiści, nie możemy tego nadrobić.

FWIW, całkowicie zgadzam się co do fatalnych interfejsów większości produktów konsumenckich. Piszę teraz kod interfejsu użytkownika od około 25 lat i dążę do elegancji i prostoty. W rzeczywistości jest to problem, ponieważ tak dużo o tym myślę, teraz nie mogę znaleźć źle zaprojektowanych interfejsów użytkownika, więc moja biedna żona kończy większość urządzeń w naszym centrum medialnym.

Ponieważ programiści nie są doskonali.

Jestem programistą osadzonych rzeczy. Część mojego kodu nie jest idealna. Większość mojego osadzonego kodu jest szybka.

Naprawienie problemów z wydajnością na końcu projektu jest bardzo trudne.

Czasami, aby uprościć (a zatem przetestować, opracować w realistycznym czasie, a nie fatalnie buggy) nakładamy różne warstwy, takie jak zdalne wprowadzanie do „usługi”, która nie jest częścią głównej aplikacji. Wynik końcowy, opóźnienie. Alternatywą jest umieszczenie wszystkiego w monolitycznej aplikacji, która jest wadliwą katastrofą w C lub C ++ (dwa najczęściej osadzane języki).

Czasami twoje urządzenie wbudowane ma harmonogram procesu, który nie robi tego, co chce użytkownik. Cholernie trudne do naprawienia jako programista osadzony.

Złożoność powoduje opóźnienie z powodu opóźnienia w nakładaniu warstw. Poprosiłeś o funkcje. Wypróbuj naprawdę starą Nokię, jak stara 3210. Szybki interfejs użytkownika. Niewiele funkcji.

Twierdzę, że programiści nie są mądrzejsi, więc szybszy sprzęt jest pochłaniany przez abstrakty, aby zapobiec wzajemnemu zabijaniu się funkcji. (Lub nie, w przypadku twojego iPhone'a)

Wydajność interfejsu użytkownika musi być wymogiem testowania w miarę postępu projektowania.

Jeśli nie zostanie określony, programista przyzwyczai się do tego. Wszyscy to robimy. „Moje dziecko nie jest brzydkie”

I to nie są języki GC; osadzona Realtime Java jest tak szybka, że ​​przerażająca. (Z drugiej strony osadzony Python jest totalnym psem)

Piszę program, który odczytuje przełączniki na wejściach cyfrowych jako interfejs użytkownika. Nadal muszę odbić przełącznik, więc naprawdę szybkie jego dotknięcie nie działa, ponieważ odbijanie ma kilka warstw w górę. Idealnie byłoby mieć logikę odbijania na dole stosu oprogramowania układowego, ale nie tak działa sprzęt.

Niektóre odtwarzacze DVD po prostu uruchamiają skrypt „wysuwania”, aby wykonać wysuwanie. Twój DVR mógł zastosować to podejście, aby utrzymać rozsądne koszty rozwoju. Następnie oszczędzasz procesor lub pamięć RAM i jest do bani.

Czy to dlatego, że wszystkie zostały napisane w zarządzanych, odśmiecanych językach zamiast w natywnym kodzie?

Nie. Powolny kod niezależnie od tego będzie działał słabo. Oczywiście, określony język może wprowadzać pewne klasy problemów podczas rozwiązywania innych. Ale dobrzy programiści są w stanie znaleźć obejścia, mając wystarczająco dużo czasu.

Czy to programiści napisali oprogramowanie dla tych urządzeń?

Częściowo. W wielu przypadkach jest to prawdopodobnie co najmniej jeden czynnik. Jest to niefortunny efekt uboczny branży, w której dobrzy programiści są bardzo poszukiwani i mają małą podaż. Również przepaść między różnymi poziomami umiejętności technicznych może być dość duża. Jest więc oczywiste, że czasami programiści, którym powierzono zadanie wdrożenia określonego oprogramowania, mogą pogratulować tylko za jego uruchomienie (w pewnym sensie).

We wszystkich tych przypadkach twórcy aplikacji wiedzieli dokładnie, na którą platformę sprzętową są kierowani i jakie są jej możliwości; czy nie wzięli tego pod uwagę?

Częściowo. Po pierwsze, dokładna platforma sprzętowa prawdopodobnie nie jest znana, ponieważ często jest ona negocjowana równolegle z różnymi producentami podczas opracowywania oprogramowania. W rzeczywistości mogą wystąpić nawet niewielkie (ale niekoniecznie nieznaczne) zmiany w sprzęcie bazowym po początkowej wersji. Zgadzam się jednak, że ogólne możliwości będą znane.

Część problemu polega na tym, że oprogramowanie prawdopodobnie nie jest opracowywane na sprzęcie, odbywa się to w emulatorach. Utrudnia to rozliczenie prawdziwej wydajności urządzenia, nawet jeśli emulatory są w 100% dokładne - a tak nie jest.

Oczywiście nie usprawiedliwia to niewystarczającego testowania odpowiedniego prototypowego sprzętu przed wydaniem. Ta wina prawdopodobnie leży poza kontrolą dev / qa.

Czy to ten facet, który krąży w kółko powtarzając: „optymalizacja jest źródłem wszelkiego zła”, czy sprowadził ich na manowce?

Nie. Jestem pewien, że i tak go nie słuchają; w przeciwnym razie nie byłby tak często cytowany (to powinna być „ przedwczesna optymalizacja ...”). :-RE

Bardziej prawdopodobne jest, że zbyt wielu programistów przyjmuje jedną z 2 skrajności w zakresie optymalizacji.

• Albo zignorują to całkowicie.
• Lub mają obsesję na punkcie drobiazgów, które nie mają nic wspólnego z rzeczywistymi wymaganiami wydajności. W efekcie budżet się kończy, a kod jest zbyt zaciemniony, aby bezpiecznie zoptymalizować rzeczywiste problemy z wydajnością.

Czy to mentalność „och, to tylko dodatkowe 100 ms” za każdym razem, aż wszystkie milisekundy sumują się w minutach?

Możliwie. Oczywiście, jeśli Sleep(100)został użyty jako odpowiednik bibuły stosowanej do spowolnienia krwawienia zerwanej kończyny - należy się spodziewać problemów. Podejrzewam jednak, że problem jest bardziej subtelny.

Chodzi o to, że nowoczesny sprzęt komputerowy (w tym urządzenia wbudowane) jest znacznie szybszy, niż ludzie się im przypisują. Większość ludzi, nawet „doświadczonych” programistów, nie docenia szybkości komputerów. 100ms to długi czas - bardzo długi czas . I tak się składa, że ​​ten „bardzo długi czas” tnie na dwa sposoby:

• Po pierwsze, programiści niepotrzebnie martwią się tym, co komputer robi wyjątkowo szybko. (Zdarza się, że właśnie taka troska o „ zwiększenie wartości 300 razy na sekundę ” doprowadziła mnie tutaj.)
• Drugim jest to, że czasami nie okazują należytej troski, gdy rzeczy zajmują bardzo dużo czasu (w skali czasowej obliczeń). Więc:
  • jeśli zignorują skutki opóźnienia podczas komunikacji przez sieć lub urządzenie pamięci masowej;
  • jeśli zignorują wpływ wątku zablokowanego i czekają na inny wątek;
  • jeśli zapomną o tym, ponieważ komputery działają tak szybko, bardzo często są w stanie powtarzać zadania znacznie częściej niż powinny, bez wiedzy dewelopera o problemie
  • ... jeśli wystąpi jakakolwiek kombinacja takich niedopatrzeń, procedura niespodziewanie zadziała bardzo wolno (w skali czasowej obliczeń). Kilka powtórzeń i będzie to nawet zauważalne przez ludzi - ale może być trudne do ustalenia, ponieważ setki powiązanych ze sobą rzeczy szybko działają same.

Czy to moja wina, że ​​kupili te produkty w pierwszej kolejności?

Tak, zdecydowanie. Cóż, nie ty osobiście, ale ogólnie konsumenci. Produkty są sprzedawane (i kupowane ) według list kontrolnych funkcji. Zbyt niewielu konsumentów wymaga lepszej wydajności.

Aby zilustrować mój punkt widzenia: kiedy ostatni raz chciałem kupić telefon komórkowy, sklep nie mógł nawet zaoferować modelu demonstracyjnego do zabawy w sklepie. Wszystko, co mieli, to plastikowe skorupy z naklejkami pokazujące, jak będzie wyglądał ekran. Nie możesz nawet poczuć takiej wagi - nie mówiąc już o wydajności lub użyteczności. Chodzi mi o to, że jeśli wystarczająca liczba osób sprzeciwi się temu modelowi biznesowemu i zagłosuje swoimi portfelami, aby wyrazić swój sprzeciw, stanowimy jeden mały krok we właściwym kierunku.

Ale oni nie, więc nie jesteśmy; i co roku nowe telefony komórkowe działają wolniej na szybszym sprzęcie.

(Pytania nie zadawane.)

• Czy winni są ludzie marketingu? Częściowo. Potrzebują dat wydania. A kiedy pojawia się wspomniana data, wybór między „uruchom ją” a „przyspiesz” nie jest żadnym problemem.
• Czy winni są sprzedawcy? Częściowo. Chcą więcej funkcji na liście kontrolnej. Przeszukują listy funkcji i ignorują wydajność. Niekiedy składają nierealne obietnice.
• Czy winni są menedżerowie? Częściowo. Niedoświadczeni menedżerowie mogą popełniać wiele błędów, ale nawet bardzo doświadczeni menedżerowie mogą (całkiem słusznie) poświęcić czas na rozwiązanie problemów z wydajnością na rzecz innych problemów.
• Czy winni są specyfikacje? Częściowo. Jeśli coś pozostanie poza specyfikacją, o wiele łatwiej o tym później „zapomnieć”. A jeśli nie jest to wyraźnie określone, jaki jest cel? (Chociaż osobiście uważam, że jeśli zespół jest dumny ze swojej pracy, mimo wszystko martwią się wydajnością).
• Czy winą jest edukacja? Może. Edukacja prawdopodobnie zawsze będzie się opierać. Z pewnością nie podoba mi się „edukacja”, która szybko wypuszcza początkujących z powierzchownym zrozumieniem tworzenia oprogramowania. Jednak edukacja poparta teorią i wpajająca kulturę uczenia się nie może być zła.
• Czy aktualizacje są winne? Częściowo. Nowe oprogramowanie, stary sprzęt naprawdę kusi los. Nawet przed wydaniem wersji X planuje się X + 1. Nowe oprogramowanie jest kompatybilne, ale czy stary sprzęt jest wystarczająco szybki? Czy zostało przetestowane? Szczególna poprawka wydajności może zostać wprowadzona do nowego oprogramowania - zachęcając do niewłaściwej aktualizacji oprogramowania.

Zasadniczo uważam, że istnieje wiele czynników. Więc niestety nie ma srebrnej kuli, aby to naprawić. Ale to nie znaczy, że jest to los i mrok. Istnieją sposoby na poprawę sytuacji.

Więc w którym momencie coś poszło nie tak z tymi produktami?

IMHO tak naprawdę nie możemy zidentyfikować żadnego pojedynczego punktu. Istnieje wiele czynników, które ewoluowały w czasie.

• Liczniki fasoli: redukcja kosztów, czas na rynku. Ale czy znowu dokonalibyśmy postępów, które osiągnęliśmy bez presji?
• Wysoki popyt i niska podaż wykwalifikowanych pracowników w branży. Nie tylko programiści, ale także menedżerowie, testerzy, a nawet sprzedawcy. Brak umiejętności i doświadczenia prowadzi do błędów. Ale znowu prowadzi to również do nauki.
• Najnowocześniejsza technologia. Dopóki technologia nie dojrzeje, będzie regularnie gryźć w nieoczekiwany sposób. Ale z drugiej strony często zapewniało to szereg korzyści.
• Złożona komplikacja. Z biegiem czasu branża ewoluowała: dodając więcej narzędzi, technologii, warstw, technik, abstrakcji, sprzętu, języków, odmian, opcji. To w pewien sposób uniemożliwia „pełne” zrozumienie nowoczesnych systemów. Jednak w rezultacie jesteśmy w stanie zrobić znacznie więcej w znacznie krótszym czasie.

Co my, programiści, możemy zrobić, aby uniknąć zadawania bólu naszym klientom?

Mam kilka sugestii (zarówno technicznych, jak i nietechnicznych), które mogą pomóc:

• W najprostszy możliwy sposób - użyj własnego produktu. Nie ma to jak doświadczenie z pierwszej ręki, które ujawnia rzeczy, które są niezręczne, wolne lub niewygodne. Będziesz jednak musiał świadomie unikać omijania braków z powodu „wiedzy poufnej”. Np. Jeśli nie masz problemów z synchronizacją kontaktów, ponieważ robisz to ze backdoorowym skryptem Python - nie używasz „produktu”. Co powoduje kolejny punkt ...
• Słuchaj swoich użytkowników (najlepiej z pierwszej ręki, ale przynajmniej z drugiej ręki poprzez wsparcie). Wiem, że programiści (ogólnie) wolą pozostać w ukryciu i unikać interakcji międzyludzkich; ale to nie pomaga odkryć problemów, z jakimi spotykają się inni ludzie podczas korzystania z Twojego produktu. Np. Możesz nie zauważyć, że opcje menu są wolne, ponieważ znasz wszystkie skróty i używasz ich wyłącznie. Nawet jeśli instrukcja w pełni dokumentuje wszystkie skróty, niektóre osoby nadal będą preferować menu - mimo że są zbyt wolne.
• Staraj się stale doskonalić umiejętności i wiedzę techniczną. Rozwijaj umiejętność krytycznej analizy wszystkiego, czego się nauczysz. Regularnie ponownie ocenia swoją wiedzę. W niektórych przypadkach przygotuj się na zapomnienie tego, co myślałeś, że wiesz. Co powoduje ...
• Niektóre technologie / techniki mogą być bardzo trudne, co prowadzi do subtelnych nieporozumień i nieprawidłowych implementacji. Inne w wyniku ewolucji powszechnej wiedzy lub dostępnych narzędzi mogą popaść w nie lub nie (np. Singletony). Niektóre tematy są tak podstępne, że rodzą masę „hokus-pokusów”, które rozprzestrzeniają ogromną ilość dezinformacji. Moim szczególnym błędem jest dezinformacja dotycząca wielowątkowości. Dobra wielowątkowa implementacja może znacznie poprawić wrażenia użytkownika. Niestety, wiele źle poinformowanych podejść do wielowątkowości znacznie obniży wydajność, zwiększy liczbę błędnych błędów, zwiększy ryzyko martwej blokady, skomplikuje debugowanie itp. Pamiętaj więc: tylko dlatego, że powiedział to „ekspert”, nie jest prawdą.
• Przejąć na własność. (Nie, serio, nie gram w bingo w sali konferencyjnej.) Negocjuj z menedżerami, właścicielami produktów, sprzedawcami, aby uzyskać informacje o funkcjach wydajności, które mają pierwszeństwo przed niektórymi elementami listy kontrolnej. Wymagaj lepszych specyfikacji. Nie dziecinnie, ale zadając pytania, które skłaniają ludzi do myślenia o wydajności.
• Bądź wymagającym konsumentem. Wybierz telefon, który ma mniej funkcji, ale jest szybszy. (Nie szybszy procesor, szybszy interfejs użytkownika.) Więc chwal się tym ! Im więcej konsumentów zacznie wymagać wydajności, tym więcej liczników fasoli rozpocznie budżetowanie.

Twój pierwszy błąd i prawdopodobnie to, dlaczego masz głos w dół, zasługuje na rażąco oczywistą przesadę. Czy naprawdę uważasz, że iPhone i iPad są takie złe?

Ostatecznie klient jest odpowiedzialny. Wszystko sprowadza się do kosztu i tego, co klient jest gotowy zapłacić i co otrzymuje w zamian. Jeśli wybiorą cechy zamiast prędkości, właśnie to dostaną. Jeśli wybiorą cenę zamiast prędkości, to zostanie zbudowana i sprzedana. Jeśli wizerunek marki jest ważniejszy ... Ostatecznie klient decyduje o swoim portfelu, co jest ważne, a co nie. Masz wybór, aby zostać markową dziwką i kupować produkty, ponieważ wszyscy inni lub niezależny myśliciel, szukają połysku i marketingowego szumu i kupują coś, co spełnia Twoje potrzeby.

Obwiniasz programistów. Napisali kod, oczywiście, ale nie zdefiniowali i nie powinni definiować wymagań klientów, sprzętu, kosztu BOM, kosztu prac badawczo-rozwojowych, budżetu marketingowego ..... wszystkich rzeczy, które idą do stworzenia produktu , to nie jest oprogramowanie.

Zastosowane technologie, używane języki itp. Nie mają z tym nic wspólnego. Źli kontra dobrzy programiści, nie ma z tym nic wspólnego. Każdy na wpół przyzwoity programista może przyspieszyć działanie kodu, być bardziej responsywnym i być najlepszym. Z mojego doświadczenia wynika, że ​​przyzwoici programiści nie zbankrutowali firmy, kiedy zostali zmuszeni do podjęcia decyzji, podczas gdy pół przyzwoici narzekają, jak „lepszym” powinno być.

Przedwczesna optymalizacja jest czasem zła, ale nie wtedy, gdy jest wymagana do dobrego doświadczenia użytkownika lub dobrej żywotności baterii w wystarczająco ograniczonym systemie. Błąd polega na tym, że nadaje się wyższy priorytet czystemu programowaniu inżynierii oprogramowania niż gotowaniu, niezależnie od tego, co zapewnia dobre wrażenia użytkownika i przyzwoitą żywotność baterii jako wyższy priorytet na początku projektu, nawet jeśli jest o wiele trudniejszy w utrzymaniu i krótki łączy pewnie starannie zaprojektowane stosy oprogramowania i metodologię.

Jeśli masz iPhone 3G, Apple wydało kilka aktualizacji systemu operacyjnego, które zostały zoptymalizowane tylko dla nowszych urządzeń. Późniejsze aktualizacje systemu operacyjnego 3G mogą zapewnić nieco lepszą wydajność 3G.

Rejestrator zajmuje tyle czasu, aby zmienić kanały, ponieważ najpierw musi zrzucić buforowane dane, a następnie ustawić w kolejce kolejny bufor pełen danych dla nowego oglądanego kanału. Bufor najprawdopodobniej jest przechowywany na dysku twardym, więc operacje te wymagają czasu (a ponadto mogą wypełniać bufor tylko w czasie rzeczywistym). W przypadku DVR nigdy nie oglądasz programów „na żywo”, zawsze jest ono opóźnione (nieprzypadkowo, jest opóźnione o tyle samo, co postrzegane opóźnienie przy przełączaniu kanałów). Można to łatwo zweryfikować, oglądając program sportowy w tym samym czasie, gdy słuchasz go w radiu.

Myślę, że powodem jest to, że większość aplikacji kierowanych przez konsumentów jest kontrolowana i sprzedawana przez osoby, które nic nie wiedzą o oprogramowaniu, i zatrudniają programistów na podstawie ich CV lub zaleceń jakiegoś menedżera „nic-nic”, w przeciwieństwie do ich rzeczywistych umiejętności i wiedzy .