Apa yang menyebabkan kinerja buruk di aplikasi konsumen? [Tutup]

DVR Comcast saya membutuhkan setidaknya tiga detik untuk merespons setiap penekanan tombol remote control, menjadikan tugas sederhana menonton televisi menjadi pengalaman menekan tombol yang membuat frustrasi. IPhone saya membutuhkan setidaknya lima belas detik untuk menampilkan pesan teks dan crash ¼ saat saya mencoba membuka aplikasi iPod; hanya dengan menerima dan membaca email sering kali membutuhkan waktu lebih dari satu menit. Bahkan navcom di mobil saya memiliki kontrol lembek dan tidak responsif, sering menelan input berturut-turut jika saya membuatnya kurang dari beberapa detik.

Ini semua merupakan perangkat konsumen akhir perangkat keras yang tetap, yang kegunaannya harus diutamakan, namun semuanya gagal pada tingkat responsif dan latensi dasar. Perangkat lunak mereka terlalu lambat .

Ada apa di balik ini? Apakah ini masalah teknis, atau masalah sosial? Siapa atau apa yang bertanggung jawab?

Apakah karena semua ini ditulis dalam bahasa sampah yang dikelola dan dikumpulkan daripada kode asli? Apakah itu programer individu yang menulis perangkat lunak untuk perangkat ini? Dalam semua kasus ini, pengembang aplikasi tahu persis platform perangkat keras apa yang mereka targetkan dan apa kemampuannya; Apakah mereka tidak memperhitungkannya? Apakah itu orang yang berulang-ulang mengulangi "optimisasi adalah akar dari semua kejahatan," apakah dia menyesatkan mereka? Apakah itu mentalitas "oh, itu hanya tambahan 100 ms" setiap kali sampai semua milidetik itu bertambah hingga menit? Apakah ini salah saya, karena telah membeli produk ini sejak awal?

Ini adalah pertanyaan subjektif, dengan tidak ada jawaban tunggal, tapi aku sering frustrasi melihat begitu banyak jawaban sini mengatakan "oh, jangan khawatir tentang kecepatan kode, kinerja tidak masalah" ketika jelas di beberapa titik itu tidak peduli untuk pengguna akhir yang terjebak dengan pengalaman yang lambat, tidak responsif, dan mengerikan.

Jadi, pada titik apa kesalahan produk ini? Apa yang bisa kita lakukan sebagai programmer untuk menghindari menimbulkan rasa sakit ini pada pelanggan kita sendiri?

Pertanyaan bagus. Apa yang saya lihat setiap hari adalah ini.

Orang-orang bekerja di aplikasi berukuran besar. Saat mereka bekerja, masalah kinerja merayap masuk, seperti halnya bug. Perbedaannya adalah - bug "buruk" - mereka berteriak "temukan aku, dan perbaiki aku". Masalah kinerja hanya duduk di sana dan semakin buruk. Pemrogram sering berpikir "Yah, kode saya tidak akan memiliki masalah kinerja. Sebaliknya, manajemen perlu membelikan saya mesin yang lebih baru / lebih besar / lebih cepat."

Faktanya adalah, jika pengembang secara berkala hanya mencari masalah kinerja (yang sebenarnya sangat mudah ) mereka bisa membersihkannya.

Sebaliknya, "keadaan seni" adalah:

1. mengandalkan kata-kata mutiara seperti "menghindari optimasi prematur" dan 90/10 hoo-haw.
2. berbicara dengan berani tentang profil, dan kadang-kadang benar-benar mencobanya, seringkali dengan hasil yang mengecewakan, seperti yang Anda lihat di semua pertanyaan SO tentang hal itu.
3. kembali pada dugaan lama yang baik, menyamar sebagai pengalaman dan pengetahuan.

Tapi sungguh, itu negatif. Untuk menjadi positif, metode ini bekerja hampir sepanjang waktu, dan itu tidak bisa lebih sederhana. Ini contoh terperinci .

Ini bukan masalah teknis, ini masalah pemasaran dan manajemen.

Anda mungkin memutar mata Anda pada saat ini, tapi tolong bersabarlah.

Apa yang dijual perusahaan adalah "produk" mereka, dan orang-orang yang mendefinisikan apa itu "manajer produk". Di perusahaan teknologi, banyak orang lain yang menimbang hal itu - ahli pengalaman pengguna, yadda yadda. Tetapi pada akhirnya, manajer produk bertanggung jawab untuk menulis spesifikasi untuk apa yang seharusnya didapatkan pengguna.

Jadi, mari kita ambil DVR Comcast Anda. Idealnya, hal-hal akan berfungsi seperti ini:

1. Manajer produk menulis dalam spec, "Ketika pengguna menekan tombol pada remote control, dan berada dalam jarak 25 kaki dari DVR, DVR harus menanggapi pers dalam waktu 250 milidetik".
2. Orang-orang teknis membangun perangkat keras, menulis perangkat lunak yang disematkan, dll.
3. Penguji QA menyetujui bahwa sistem memenuhi spesifikasi, atau mengembalikannya ke tim teknis untuk diperbaiki.

Tentu saja, banyak hal yang bisa salah:

• Manajer produk gagal memasukkan respons tombol dalam spesifikasi
• Orang-orang QA melakukan pekerjaan pengujian biasa-biasa saja terhadap spesifikasi
• Seseorang memilih teknologi yang tidak mengizinkan spek terpenuhi, sehingga persyaratannya dikerjai
• Staf teknis bertangan pendek, atau seseorang mempercepat jadwal, dan beberapa manajer berkata, "Lupakan responsif - selesaikan fitur lain ini."
• Manajer produk tidak mempublikasikan persyaratan responsif sampai selambat-lambatnya dalam permainan, tidak dapat dipenuhi pada tanggal pengiriman
• Manajemen memutuskan untuk tidak mengirimkan apa pun untuk pengujian QA sampai selarut ini, mempercepat kode lambat akan membuat produk tidak stabil

Apakah Anda melihat semua programmer yang tidak bercela di sana? Tidak ada.

Saya tidak mengatakan kita tidak bertanggung jawab sama sekali atas kinerja yang buruk - sering kali, mudah dan cepat untuk menulis kode yang baik, kuat, dan efisien seperti menulis sampah.

Tapi sungguh, jika manajemen produk dan staf QA semua tertidur di belakang kemudi, kami programmer tidak bisa menebusnya.

FWIW, saya sepenuhnya setuju tentang antarmuka yang buruk dari sebagian besar produk konsumen. Saya telah menulis kode UI sekarang selama sekitar 25 tahun, dan saya berusaha untuk keanggunan dan kesederhanaan. Ini sebenarnya masalah karena saya sangat memikirkannya, saya sekarang payah dalam mencari antarmuka pengguna yang dirancang dengan buruk, sehingga istri saya yang malang akhirnya menjalankan sebagian besar perangkat di pusat media kami.

Karena programmer tidak sempurna.

Saya seorang programmer hal-hal yang tertanam. Beberapa kode saya tidak sempurna. Sebagian besar kode tertanam saya cepat.

Untuk memperbaiki masalah kinerja pada akhir proyek sangat sulit.

Kadang-kadang, untuk menjaga hal-hal sederhana (dan karena itu dapat diuji, dikembangkan-mampu dalam waktu yang realistis, bukan buggy fatal) kami melapisi hal-hal, seperti input jarak jauh ke "layanan" yang bukan bagian dari aplikasi utama. Hasil akhir, latensi. Alternatifnya adalah meletakkan segala sesuatu dalam aplikasi monolitik adalah bencana kereta di C atau C ++ (dua bahasa embedded paling umum.)

Terkadang perangkat tertanam Anda memiliki penjadwal proses yang tidak melakukan apa yang Anda sebagai pengguna. Sangat sulit untuk diperbaiki sebagai pengembang yang disematkan.

Kompleksitas menyebabkan kelambatan, karena latensi pada layering. Anda meminta fitur. Coba Nokia yang benar-benar tua, seperti yang lama 3210. Zippy UI cepat. Tidak banyak fitur.

Saya berpendapat bahwa pengembang tidak mendapatkan yang lebih pintar, sehingga perangkat keras lebih cepat diserap pada abstraksi untuk mencegah fitur membunuh satu sama lain. (Atau tidak, untuk iPhone Anda)

Kinerja UI harus menjadi persyaratan yang Anda uji saat desain berlangsung.

Jika tidak ditentukan, pengembang akan terbiasa. Kita semua melakukan ini. "Bayiku tidak jelek"

Dan itu bukan bahasa GC; Java Realtime tertanam begitu cepat sehingga menakutkan. (Embedded Python di sisi lain adalah anjing total)

Saya menulis sebuah program yang bertuliskan switch pada input digital sebagai UI. Masih harus de-bouncing switch, jadi sangat cepat menjentikkan switch tidak berfungsi, karena de-bounce adalah beberapa lapisan ke atas. Idealnya, saya memiliki logika de-bouncing di bagian bawah tumpukan firmware, tetapi itu bukan cara perangkat keras bekerja.

Beberapa pemutar DVD hanya menjalankan skrip "eject" untuk melakukan eject. Anda DVR mungkin telah mengambil pendekatan ini untuk menjaga biaya pengembangan tetap waras. Kemudian Anda berhemat pada CPU atau RAM dan itu menyebalkan.

Apakah karena semua ini ditulis dalam bahasa sampah yang dikelola dan dikumpulkan daripada kode asli?

Tidak. Kode lambat akan berkinerja buruk. Tentu saja, bahasa tertentu dapat memperkenalkan kelas masalah tertentu sambil memecahkan yang lain. Tetapi programmer yang baik cukup mampu menemukan solusi yang diberikan waktu yang cukup.

Apakah itu programer individu yang menulis perangkat lunak untuk perangkat ini?

Sebagian. Dalam banyak kasus kemungkinan besar setidaknya merupakan faktor yang berkontribusi. Ini adalah efek samping yang tidak menguntungkan dari suatu industri di mana programmer yang baik dalam permintaan tinggi dan pasokan pendek. Juga jurang pemisah antara berbagai tingkat kemampuan teknis bisa sangat besar. Jadi masuk akal bahwa kadang-kadang programmer yang ditugaskan untuk mengimplementasikan perangkat lunak tertentu dapat diberi selamat hanya untuk membuatnya berfungsi (semacam).

Dalam semua kasus ini, pengembang aplikasi tahu persis platform perangkat keras apa yang mereka targetkan dan apa kemampuannya; Apakah mereka tidak memperhitungkannya?

Sebagian. Sebagai permulaan, tepatnya platform perangkat keras yang mungkin tidak diketahui, karena sering dinegosiasikan dengan berbagai produsen secara paralel selama pengembangan perangkat lunak. Bahkan, mungkin ada perubahan kecil (tapi tidak berarti tidak signifikan) untuk perangkat keras yang mendasari setelah rilis awal. Namun, saya setuju bahwa kapabilitas umum akan diketahui.

Sebagian dari masalahnya adalah bahwa perangkat lunak mungkin tidak dikembangkan pada perangkat keras, itu dilakukan dalam emulator. Ini membuat sulit untuk memperhitungkan kinerja perangkat yang sebenarnya bahkan jika emulator 100% akurat - padahal sebenarnya tidak.

Tentu saja ini tidak benar-benar membenarkan pengujian yang tidak memadai pada perangkat keras prototipe yang sesuai sebelum rilis. Kesalahan itu mungkin terletak di luar kendali dev / qa.

Apakah itu orang yang berulang-ulang mengulangi "optimisasi adalah akar dari semua kejahatan," apakah dia menyesatkan mereka?

Tidak. Aku cukup yakin mereka toh tidak mendengarkannya; kalau tidak, dia tidak akan salah mengutip begitu sering (itu seharusnya " optimasi prematur ..."). :-D

Itu lebih mungkin bahwa terlalu banyak programmer mengambil salah satu dari 2 ekstrim terkait dengan optimasi.

• Entah mereka mengabaikannya sama sekali.
• Atau mereka terobsesi dengan hal-hal kecil yang tidak ada hubungannya dengan persyaratan kinerja aktual . Efek bersihnya adalah anggaran habis dan kode terlalu dikaburkan untuk mengoptimalkan masalah kinerja nyata dengan aman.

Apakah itu mentalitas "oh, itu hanya tambahan 100 ms" setiap kali sampai semua milidetik itu bertambah hingga menit?

Mungkin. Jelas jika Sleep(100)telah digunakan sebagai setara dengan kertas tisu yang digunakan untuk memperlambat pendarahan anggota badan yang terputus - maka masalah yang diharapkan. Namun, saya curiga masalahnya lebih halus dari itu.

Masalahnya adalah perangkat keras komputasi modern (termasuk perangkat yang disematkan) jauh lebih cepat daripada yang diberikan orang kepada mereka. Kebanyakan orang, bahkan pemrogram "berpengalaman" gagal menghargai seberapa cepat komputer itu. 100 ms adalah waktu yang lama - waktu yang sangat lama . Dan seperti yang terjadi, "waktu yang sangat lama" ini memotong 2 cara:

• Yang pertama adalah bahwa programmer tidak perlu khawatir tentang hal-hal yang dilakukan komputer dengan sangat cepat. (Kebetulan bahwa itu hanya masalah " meningkatkan nilai 300 kali per detik " yang membuat saya di sini di tempat pertama.)
• Yang kedua adalah bahwa mereka kadang-kadang gagal menunjukkan kekhawatiran ketika hal-hal memang memakan waktu yang sangat lama (pada skala waktu komputasi). Begitu:
  • jika mereka mengabaikan efek latensi saat berkomunikasi melalui jaringan atau dengan perangkat penyimpanan;
  • jika mereka mengabaikan dampak utas yang diblokir dan menunggu utas lainnya;
  • jika mereka lupa bahwa karena komputer bekerja sangat cepat, ia sangat mampu mengulangi tugas jauh lebih sering daripada seharusnya, tanpa pengembang menyadari masalah.
  • ... jika kombinasi dari kekeliruan semacam itu terjadi, sebuah rutinitas tiba-tiba akan berjalan sangat lambat (pada skala waktu komputasi). Beberapa pengulangan dan bahkan akan terlihat oleh manusia - tetapi mungkin sulit untuk dijabarkan karena ratusan hal yang saling berhubungan semua berjalan dengan cepat sendiri.

Apakah ini salah saya, karena telah membeli produk ini sejak awal?

Iya tentu saja. Nah, bukan Anda secara pribadi tetapi konsumen pada umumnya. Produk dijual (dan dibeli ) oleh daftar fitur. Terlalu sedikit konsumen yang menuntut kinerja yang lebih baik.

Untuk mengilustrasikan poin saya: Terakhir kali saya ingin membeli ponsel, toko bahkan tidak dapat menawarkan model demo untuk bermain dengan di dalam toko. Yang mereka miliki hanyalah kerang plastik dengan stiker untuk menunjukkan seperti apa tampilan layar itu. Anda bahkan tidak bisa merasakan bobot seperti itu - apalagi kinerja atau kegunaan. Maksud saya adalah jika cukup banyak orang yang keberatan dengan model bisnis itu, dan memilih dengan dompet mereka untuk menyuarakan keberatan mereka, kami akan menjadi satu langkah kecil ke arah yang benar.

Tetapi mereka tidak, jadi kita tidak; dan setiap tahun telepon seluler baru berjalan lebih lambat pada perangkat keras yang lebih cepat.

(Pertanyaan tidak diajukan.)

• Apakah orang pemasaran yang harus disalahkan? Sebagian. Mereka membutuhkan tanggal rilis. Dan ketika kata tanggal tampak, pilihan antara "membuatnya bekerja" dan "membuatnya lebih cepat" adalah hal yang mudah.
• Apakah orang penjualan harus disalahkan? Sebagian. Mereka menginginkan lebih banyak fitur dalam daftar periksa. Mereka mengacaukan daftar fitur dan mengabaikan kinerja. Mereka (kadang-kadang) membuat janji yang tidak realistis.
• Apakah manajer harus disalahkan? Sebagian. Manajer yang tidak berpengalaman mungkin membuat banyak kesalahan, tetapi bahkan manajer yang sangat berpengalaman pun dapat (dengan tepat) mengorbankan waktu untuk menyelesaikan masalah kinerja demi kepentingan orang lain.
• Apakah spesifikasi yang patut disalahkan? Sebagian. Jika ada sesuatu yang terlewatkan dari spesifikasi, akan jauh lebih mudah untuk "melupakan" nanti. Dan jika tidak disebutkan secara spesifik, apa targetnya? (Meskipun saya secara pribadi percaya bahwa jika suatu tim bangga dengan pekerjaannya, mereka akan mengkhawatirkan kinerja bagaimanapun juga.)
• Apakah pendidikan yang harus disalahkan? Mungkin. Pendidikan mungkin akan selalu berada di belakang. Saya tentu saja tidak menyetujui "pendidikan" yang dengan cepat menghasilkan pemula dengan pengembangan perangkat lunak pemahaman yang dangkal. Namun, pendidikan yang didukung oleh teori, dan menanamkan budaya belajar tidak mungkin buruk.
• Apakah upgrade harus disalahkan? Sebagian. Perangkat lunak baru, perangkat keras lama benar-benar menggoda nasib. Bahkan sebelum versi X dirilis, X +1 sedang dalam perencanaan. Perangkat lunak baru ini kompatibel, tetapi apakah perangkat keras yang lama cukup cepat? Apakah sudah diuji? Perbaikan kinerja tertentu dapat dimasukkan ke dalam perangkat lunak baru - mendorong pembaruan perangkat lunak yang keliru.

Pada dasarnya, saya percaya ada banyak faktor yang berkontribusi. Jadi, sayangnya tidak ada peluru perak untuk memperbaikinya. Tapi itu tidak berarti itu adalah malapetaka dan kesuraman. Ada beberapa cara untuk berkontribusi dalam memperbaiki berbagai hal.

Jadi, pada titik apa kesalahan produk ini?

IMHO kita tidak bisa mengidentifikasi satu titik pun. Ada banyak faktor yang berkontribusi yang berkembang seiring waktu.

• Penghitung kacang: pemotongan biaya, waktu pasar. Tetapi sekali lagi apakah kita akan membuat kemajuan yang kita capai tanpa tekanan?
• Permintaan tinggi dan pasokan rendah orang-orang terampil di industri. Tidak hanya programmer, tetapi juga manajer, penguji, dan bahkan orang-orang penjualan. Kurangnya keterampilan & pengalaman menyebabkan kesalahan. Tetapi sekali lagi itu juga mengarah pada pembelajaran.
• Teknologi mutakhir. Sampai suatu teknologi matang, ia akan secara teratur menggigit dengan cara yang tidak terduga. Tapi sekali lagi itu sering memberikan sejumlah keunggulan di tempat pertama.
• Komplikasi yang diperberat. Seiring waktu, industri telah berevolusi: menambahkan lebih banyak alat, teknologi, lapisan, teknik, abstraksi, perangkat keras, bahasa, variasi, opsi. Ini membuatnya agak tidak mungkin untuk memiliki pemahaman "penuh" tentang sistem modern. Namun, kami juga mampu melakukan lebih banyak dalam waktu yang jauh lebih singkat.

Apa yang bisa kita lakukan sebagai programmer untuk menghindari menimbulkan rasa sakit ini pada pelanggan kita sendiri?

Saya punya beberapa saran (baik teknis dan non-teknis) yang dapat membantu:

• Sedapat mungkin - gunakan produk Anda sendiri. Tidak ada yang seperti pengalaman tangan pertama untuk mengungkapkan hal-hal yang canggung, lambat atau tidak nyaman. Namun Anda perlu secara sadar menghindari melewati kekurangan karena "pengetahuan orang dalam". Misalnya. Jika Anda tidak memiliki masalah menyinkronkan kontak karena Anda melakukannya dengan skrip Python backdoor - Anda tidak menggunakan "produk". Yang memunculkan poin berikutnya ...
• Dengarkan pengguna Anda (lebih disukai tangan pertama, tetapi setidaknya tangan kedua melalui dukungan). Saya tahu programmer (umumnya) lebih memilih untuk tetap tersembunyi dan menghindari interaksi manusia; tetapi itu tidak membantu Anda menemukan masalah yang dialami orang lain saat menggunakan produk Anda. Misalnya, Anda mungkin tidak melihat bahwa opsi menu lambat, karena Anda tahu semua pintasan dan menggunakannya secara eksklusif. Bahkan jika manual sepenuhnya mendokumentasikan semua cara pintas, beberapa orang masih akan lebih suka menu - meskipun lambat.
• Berusaha keras untuk meningkatkan keterampilan teknik dan pengetahuan Anda secara berkelanjutan. Kembangkan keterampilan untuk menganalisis secara kritis semua yang Anda pelajari. Menilai kembali pengetahuan Anda secara teratur. Dalam beberapa kasus, bersiaplah untuk melupakan apa yang Anda pikir Anda tahu. Yang menampilkan ...
• Beberapa teknologi / teknik bisa sangat sulit mengarah pada kesalahpahaman halus dan implementasi yang salah. Orang lain melalui evolusi pengetahuan umum atau alat yang tersedia mungkin jatuh atau tidak disukai (misalnya Singleton). Beberapa topik sangat rumit sehingga mereka mengembangbiakkan "pakar-pakar hocus-pocus" yang menyebarkan sejumlah besar informasi yang salah. Salah satu kesalahan saya adalah informasi yang salah seputar multi-threading. Implementasi multi-utas yang baik dapat secara signifikan meningkatkan pengalaman pengguna. Sayangnya banyak pendekatan yang salah informasi untuk multi-threading secara signifikan akan mengurangi kinerja, meningkatkan bug yang tidak menentu, meningkatkan risiko dead-lock, menyulitkan debugging dll. Jadi ingat: hanya karena "pakar" mengatakannya, tidak menjadikannya benar.
• Ambil kepemilikan. (Tidak serius, saya tidak bermain bingo ruang dewan.) Bernegosiasi dengan manajer, pemilik produk, tenaga penjualan untuk fitur kinerja yang diutamakan daripada beberapa item daftar periksa. Menuntut spesifikasi yang lebih baik. Bukan kekanak-kanakan, tetapi dengan mengajukan pertanyaan yang membuat orang berpikir tentang kinerja.
• Jadilah konsumen yang cerdas. Pilih ponsel yang memiliki lebih sedikit fitur tetapi lebih cepat. (CPU tidak lebih cepat, UI lebih cepat.) Lalu sesumbar tentang itu ! Semakin banyak konsumen mulai menuntut kinerja, semakin banyak penghitung kacang akan mulai menganggarkan untuk itu.

Kesalahan pertama Anda, dan mungkin mengapa Anda mendapat suara rendah itu layak dibesar-besarkan. Apakah Anda benar-benar berharap untuk percaya bahwa iPhone dan iPad seburuk itu.

Pada akhirnya pelanggan bertanggung jawab. Biaya dan apa yang pelanggan siap untuk membayar dan apa yang mereka dapatkan sebagai imbalan. Jika mereka memilih fitur daripada kecepatan, itulah yang mereka dapatkan. Jika mereka memilih harga daripada kecepatan, itulah yang dibangun dan dijual. Jika citra merek lebih penting ..... Pada akhirnya pelanggan memutuskan dengan dompet mereka, apa yang penting dan apa yang tidak. Anda memiliki pilihan untuk menjadi pelacur merek dan membeli produk karena semua orang melakukannya, atau menjadi pemikir independen, melihat di balik gloss dan hype pemasaran, dan membeli sesuatu yang memenuhi kebutuhan Anda.

Anda menyalahkan programmer. Mereka menulis kode, tentu saja, tetapi mereka tidak mendefinisikan, dan seharusnya tidak mendefinisikan, persyaratan pelanggan, perangkat keras, biaya BOM, biaya R&D, anggaran pemasaran ..... semua hal yang terjadi untuk membuat suatu produk , itu bukan perangkat lunak.

Teknologi yang digunakan, bahasa yang digunakan dll, tidak ada hubungannya dengan ini. Pengembang buruk vs bagus, tidak ada hubungannya dengan itu. Setengah programmer yang baik dapat membuat kode berjalan lebih cepat, lebih responsif, menjadi yang terbaik. Pengalaman saya adalah pemrogram yang baik tidak membuat bisnis bangkrut ketika dibiarkan mengambil keputusan, sementara setengah yang layak mengeluh betapa "lebih baik" itu "seharusnya".

Optimalisasi prematur kadang-kadang buruk, tetapi tidak saat dibutuhkan untuk pengalaman pengguna yang baik atau daya tahan baterai yang baik dalam sistem yang cukup terbatas. Kegagalan adalah kesalahan dalam memberikan prioritas yang lebih tinggi untuk membersihkan rekayasa perangkat lunak yang dapat dipelihara daripada memasak dalam apa pun untuk memberikan pengalaman pengguna yang baik dan masa pakai baterai yang layak sebagai prioritas yang lebih tinggi pada awal proyek, bahkan jika itu jauh lebih sulit untuk dipertahankan dan dipersingkat. mengitari beberapa tumpukan perangkat lunak dan metodologi yang dirancang dengan rapi.

Jika Anda memiliki iPhone 3G, Apple merilis beberapa pembaruan OS yang hanya dioptimalkan untuk perangkat yang lebih baru. Pembaruan OS selanjutnya untuk 3G dapat memberikan kinerja yang sedikit lebih baik pada 3G.

DVR Anda membutuhkan waktu lama untuk mengubah saluran karena harus terlebih dahulu membuang data yang disangga, dan kemudian mengantri buffer lain yang penuh dengan data untuk saluran baru yang Anda tonton. Buffer ini kemungkinan besar disimpan di hard drive sehingga operasi ini membutuhkan waktu (ditambah lagi hanya dapat mengisi buffer secara real time). Dengan DVR Anda tidak pernah menonton pemrograman "langsung", ia selalu tertunda (tidak secara kebetulan, ia tertunda pada waktu yang sama dengan penundaan yang Anda rasakan saat berpindah saluran). Ini dapat dengan mudah diverifikasi dengan menonton program olahraga pada saat yang sama ketika Anda mendengarkannya di radio.

Saya pikir alasannya adalah bahwa sebagian besar aplikasi yang diarahkan konsumen dikendalikan dan dipasarkan oleh orang-orang yang tidak tahu apa-apa tentang perangkat lunak, dan mempekerjakan pengembang berdasarkan resume mereka atau rekomendasi dari beberapa manajer yang tidak ada apa-apa, yang bertentangan dengan keterampilan dan pengetahuan mereka yang sebenarnya. .