Mengapa perangkat lunak tidak dapat diandalkan seperti mobil? [Tutup]

Saya punya pengguna yang menanyakan pertanyaan ini kepada saya. Kita tahu bahwa mobil mogok, tetapi itu karena sesuatu yang fisik (kecuali jika perangkat lunak terlibat!).

Saya mencoba menjawab bahwa perangkat lunak adalah industri yang jauh lebih muda, tetapi pengguna membalas dengan "bukankah industri mobil menjadi jauh lebih stabil daripada dan dapat diandalkan dengan lebih sedikit orang?".

Saya juga mencoba menjawab bahwa perangkat lunak lebih kompleks, tetapi pengguna membalas bahwa ada ribuan komponen yang membentuk sebuah mobil. Orang-orang yang mendesain dan membuat mobil umumnya hanya mengetahui komponen mereka dengan baik, tetapi mereka semua akhirnya bekerja bersama sebagai hasil akhirnya.

Jadi, mengapa perangkat lunak tidak dapat diandalkan seperti mobil?

Premis dari pertanyaan Anda benar-benar salah: Perangkat lunak tidak "kurang dapat diandalkan" daripada mobil. Ada miliaran demi miliaran perangkat di luar sana yang menjalankan perangkat lunak tertanam 24x7, selama bertahun-tahun tanpa masalah. Heck, ada yang ada di mobil, dan kontrol / monitor mesin. Jadi, bagaimana bisa perangkat lunak menjadi kurang dapat diandalkan daripada mobil, jika mobil itu sendiri bergantung pada perangkat lunak?

Saya merancang perangkat lunak dan komponen mekanis.

Ini adalah kompleksitas.

Karena ada jutaan "bagian" dalam perangkat lunak modern.

Bagian-bagian perangkat lunak sangat rumit dan memiliki banyak NEGARA. Bagian mekanis yang tidak bergerak tidak memiliki status.

Bagian yang bergerak secara mekanis memiliki posisi (satu variabel).

Sebuah program yang sedang berjalan dan menggunakan RAM 1Mb memiliki status sejuta byte. Itu jauh lebih keadaan daripada sistem mekanis normal.

Akan ada kombinasi status yang tidak pernah diuji karena jarang terjadi. Dalam sistem mekanis (seperti mobil), mudah untuk memeriksa apakah bagian-bagian mekanis tidak saling mengenai selama operasi. Perangkat lunak CAD mekanis yang saya gunakan di tempat kerja melakukannya secara otomatis.

Jika Anda membuat mesin dari bagian yang tidak terlihat dan tidak dapat disentuh, dan memiliki jutaan bagian yang bergerak yang semuanya saling meleset, itu akan seperti program sederhana.

Bahkan "hello world" berjalan pada sistem operasi. Sistem 8 bit lama dan sistem operasi komputer mini cukup dapat diandalkan karena sederhana.

Hal-hal seperti DLL dan pustaka bersama diganti sebagai bagian dari pembaruan virus atau pemasangan perangkat lunak dan kemudian program yang menarik tidak berfungsi. Agak seperti mengganti ban di mobil Anda untuk ban sepeda. Beberapa kondisi tepi mengganggu fungsi perpustakaan (jangan bertindak seperti yang diharapkan program).

Program yang ditulis dalam bahasa seperti Java yang tidak memungkinkan banyak interaksi yang tidak dirancang antara objek (penggunaan kembali pointer, array batas meluap) umumnya cukup dapat diandalkan begitu Anda membuatnya berfungsi sama sekali.
Ketika Anda menggunakan sistem operasi dengan pustaka statis, begitu sebuah program bekerja, ia akan tetap berfungsi (tetapi masih memiliki banyak kondisi tepi, berdasarkan pada ukuran kondisinya).

Dave Parnas menulis tentang mendapatkan keandalan dalam perangkat lunak dengan membuat status program lebih kecil. Pemrograman fungsional yang ketat melakukan hal yang sama dengan memaksa penugasan statis tunggal.

Ini masalah pilihan konsumen.

Jika konsumen menuntut perangkat lunak agar dapat diandalkan seperti Honda Civic saya (berbeda dengan Ford Maverick lama saya), itu akan menjadi. Beberapa organisasi menuntut perangkat lunak yang andal, dan mereka mendapatkannya, biasanya untuk perangkat lunak yang disematkan, kadang-kadang untuk hal-hal yang penting untuk keselamatan seperti misi luar angkasa dan kontrol lalu lintas udara. Perangkat lunaknya masih belum sempurna, tetapi juga mobil.

Namun, pelanggan menuntut kualitas lain dalam perangkat lunak mereka, dan sebagian besar tidak mau membayar untuk perangkat lunak yang mungkin kurang fungsional, tentu lebih mahal, dan dikirimkan nanti hanya karena lebih dapat diandalkan.

ada ribuan bagian yang membentuk mobil.

Kalau saja komputer (dan perangkat lunak terkait) sesederhana itu.

Komputer memiliki memori sebesar apa gigabyte? Miliaran sandal jepit? Satu terabyte disk? Triliun bagian "bergerak"?

Perangkat lunak ini mungkin memiliki 10s ribu atau 100s ribu baris kode berjalan secara individu. Ditambah banyak (atau lebih) dalam unit test dan tool.

Tidak. Argumen "mobil itu rumit, juga" adalah bunk. Perangkat lunak jauh, jauh, jauh lebih kompleks daripada mobil.

Prinsip-prinsip yang membuat mesin pembakaran bekerja, dan semua komponen yang membentuk mobil tidak banyak berubah di abad yang lalu. Tentu ada peningkatan evolusi dan mobil hibrida, tetapi komponen dasarnya sama. Anda memiliki mesin, drive-train, dll. Bahkan mobil konsep dan super cepat Bugatti Veyron Anda dibuat dengan struktur dasar yang sama. Singkatnya, mendesain mobil adalah masalah yang terkenal .

Bandingkan dengan pengembangan perangkat lunak.

• Pelanggan tidak tahu apa yang mereka inginkan ketika mereka mulai. Mereka mulai berbicara tentang jet mewah, tetapi kemudian ketika mereka menyadari biaya yang mereka ingin Anda membangunnya untuk biaya skuter bertenaga kaki.
• Desain mobil membutuhkan waktu bertahun-tahun untuk beralih dari mobil konsep ke mobil konsep, dan lebih banyak lagi tahun dari sana untuk memproduksi. Kapan terakhir kali Anda memiliki kemewahan dengan perangkat lunak?
• Suku cadang mobil terbuat dari logam, tetapi komponen perangkat lunak dapat sering berubah bentuk dan antarmuka.
• Proses pembuatannya sangat berbeda. Dengan mobil, potongan diproduksi dalam jumlah massal dan potongan yang sama digunakan di berbagai kendaraan. Dengan perangkat lunak, hampir semuanya dibuat dengan tangan karena kalau tidak, barang tidak cocok.

Singkatnya, ada sejumlah alasan mengapa mobil dianggap "lebih dapat diandalkan" daripada perangkat lunak. Saya baru saja datang dengan pasangan.

Mobil bisa diandalkan. Begitu juga sebagian besar perangkat lunak.

Tapi ... mobil khusus, dan perangkat lunak khusus, keduanya memiliki masalah.

Setiap penggila mobil sungguhan, yang memodifikasi mobil berotot 1970-an, mengotak-atik, dan mengubah, dan telah rusak, dan segala macam masalah bodoh yang tidak akan ia miliki jika ia meninggalkannya semula. Tapi ... maka dia tidak akan memiliki supercharger ...

Karena mobil yang Anda kendarai telah dibuat berkali-kali, proses konstruksinya sangat halus sehingga mobil yang sama dapat dibuat pada jalur produksi berulang-ulang.

Jika itu adalah mobil canggih canggih yang dibuat dari awal begitu tidak akan dapat diandalkan, misalnya lihat seberapa jauh tingkat kegagalan dalam mobil balap formula 1. Biasanya satu atau dua mogok per perlombaan.

Perangkat lunak baru selalu sekali saja. Apa kode pemrogram tidak pernah dikodekan oleh mereka sebelumnya. Untuk mendapatkan kualitas yang sangat tinggi dalam skenario ini melibatkan biaya yang menghambat sebagian besar produk. Setiap perangkat lunak baru non-sepele adalah prototipe yang efektif.

Selain itu, ini adalah salah satu alasan utama yang menerapkan teknik teknik tradisional untuk rekayasa perangkat lunak adalah bencana.

1. Pabrikan mobil mendapatkan seluruh spesifikasi dipaku sebelum mereka menghasilkan produk "final".
2. Pengguna mobil cenderung tidak melakukan hal-hal bodoh yang tidak diharapkan oleh para desainer.
3. Mobil hanya "diperbarui" sekali per tahun (biasanya), sedangkan sebagian besar perangkat lunak diharapkan diperbarui berkali-kali per tahun.

Saya bisa melanjutkan, tetapi browser saya rasanya hampir macet ...

Sebenarnya ada alasan yang sangat sederhana.

Perangkat lunak yang menghasilkan uang adalah perangkat lunak yang mengumpulkan pangsa pasar. Lebih sering daripada tidak, perusahaan yang membawa perangkat lunak ke pasar terlebih dahulu akan menjadi perusahaan yang mendapatkan mayoritas pangsa pasar, bahkan jika perangkat lunak mereka bukan produk terbaik di pasar khusus mereka.

Konsekuensinya, fokusnya adalah membuat perangkat lunak dirilis lebih cepat dan tidak sempurna, bukan lambat dan sempurna.

Saya suka sebagian besar jawabannya sejauh ini. Inilah putaran saya di atasnya.

Biaya kegagalan lebih berat untuk mobil daripada perangkat lunak

Kegagalan mobil berpotensi menghabiskan nyawa. Bahkan kegagalan kendaraan yang tidak mengancam jiwa merupakan ketidaknyamanan yang sangat nyata bagi pengguna. Kegagalan perangkat lunak hanya berarti beberapa getah miskin dalam dukungan produksi harus bekerja lembur. Dan jika orang itu adalah karyawan bebas-waktu penuh, maka ya ampun, itu sama sekali tidak mahal. Bahkan, kualitas buruk dan manajemen yang buruk dihargai karena lembur gratis sebenarnya mengurangi biaya tenaga kerja per jam!

Tentu saja, ini tergantung pada jenis perangkat lunak yang digunakan (perangkat lunak yang menggerakkan sistem senjata, avionik atau sistem medis juga dapat memiliki efek pada kehidupan), tetapi sebuah mobil menghabiskan banyak uang dan digunakan secara cukup teratur sehingga penyimpangan dalam keandalan adalah cukup nyata dan menyakitkan. Kegagalan perangkat lunak seringkali memiliki solusi.

Pikiran lain: Mobil tampaknya dapat diandalkan tetapi mereka memiliki biaya perawatan yang pasti yang sedang berlangsung bahkan jika mobil berfungsi dengan baik, dan secara budaya, ini diterima dan bahkan merupakan pengeluaran yang membanggakan oleh orang-orang yang peduli dengan kendaraan mereka. Perangkat lunak di sisi lain, seringkali sudah rusak ketika diinstal, dan seringkali harus berubah seiring waktu, tetapi secara budaya, tidak ada yang mau membayar untuk pemeliharaan.

Yah, mobil tidak bisa diandalkan untuk sebagian besar sejarah mereka, dan pasti ada kurva belajar. Mobil telah diproduksi dalam skala besar selama sekitar 60 tahun, sedangkan perangkat lunak hanya diproduksi dalam skala besar sekitar 20-25. Dalam skala besar, pada dasarnya saya maksudkan massa cukup besar untuk membeli / menggunakannya dan ada insentif yang sangat besar untuk mencari cara untuk menyempurnakan prosedur pembuatannya.

Saya suka menganggap Mobil sebagai aplikasi. Sedangkan OS adalah jalan tempat aplikasi berjalan.

Antarmuka antara jalan dan mobil didefinisikan dengan baik. Teruji dengan baik dan secara ekstensif diperiksa untuk kompatibilitas ke belakang (yang mudah karena antarmuka yang sederhana). Namun demikian Anda memiliki beberapa masalah kompatibilitas ke belakang. Mobil tipe "Farrie" mengalami kesulitan berjalan di jalan tipe "jalan lumpur".

Meski begitu OS Anda seperti jalan perlu pemeliharaan konstan. Jembatan keluar. Mobil memakai rantai salju dan menghancurkan jalan-jalan seperti aplikasi rusak dan merusak disk dan file yang digunakan oleh OS.

Aplikasi akan ditulis pada satu OS. Tetapi secara umum mereka harus menjalankan versi OS yang berbeda (tipe jalan yang berbeda). Jadi aplikasi yang dioptimalkan perjamuan makan malam Anda dapat berjalan dengan lancar dan tanpa masalah selama itu dijalankan pada OS (Jalan Raya) yang benar, sementara kode tujuan umum lainnya (lebih sederhana) akan berjalan dengan baik di semua jenis jalan.

Antarmuka antara Aplikasi dan OS didefinisikan tetapi sangat kompleks dan selalu sedikit berfluktuasi. Terutama karena kami mengizinkan pengguna untuk memodifikasi OS mereka sendiri dengan ekstensi. Jika pemerintah mengizinkan pengguna untuk memodifikasi jalan, akan ada lebih banyak crash.

Ketika Anda mulai membatasi kemampuan pengguna untuk memodifikasi OS, keandalan aplikasi dapat menjadi hampir kokoh. Lihatlah semua perangkat yang disematkan itu. Kami tidak membiarkan pengguna di dekat OS mereka dan Anda berjalan dengan baik dan terus menerus 24/7 tanpa gangguan.

Jadi saya akan mengatakan itu bukan perangkat lunak yang tidak dapat diandalkan. Ini lebih seperti mengatakan bahwa pengguna keluar menggali lubang di jalan raya untuk aplikasi. Hei aplikasi Anda baru saja menabrak lubang yang saya gali tahun lalu dan lupa .

Pertama, pengguna Anda perlu tahu bahwa ada perangkat lunak yang sangat andal di dunia ini sehingga ia bahkan tidak menyadarinya. Pernahkah Anda melihat crash TV? Aku juga tidak.

Saya pikir alasan utama adalah perangkat lunak tidak penting. Menjadi tidak material berarti bahwa non-pengembang tidak melihat kemajuan yang terjadi. Misalnya, jika saya membuat mobil, Anda bisa melihat saya merakit bagian-bagian yang berbeda dan itu akan terlihat lebih dan lebih seperti mobil; Namun, jika Anda melihat saya pemrograman, mungkin saya akan menghabiskan berjam-jam mengutuk layar hitam dengan teks hijau melakukan pola aneh dan kemudian tiba-tiba ketika pola berubah sedikit saja saya akan terlalu bersemangat.

Karena itu, orang normal tidak menyadari kompleksitas perangkat lunak. Ketika mereka melihat jendela, mereka pikir mereka melihat program secara keseluruhan, yang sangat salah.

Selain itu, perangkat lunak jauh lebih sering disesuaikan dari pada mobil. Ketika Anda menyesuaikan mobil, Anda tidak akan menentang desainnya karena itu akan tampak bodoh. Jika mesin saya ada di depan mobil, memindahkannya ke belakang kemungkinan besar akan menjadi bencana besar. Namun, karena perangkat lunak tidak penting, jika klien meminta Anda untuk melakukan sesuatu yang sepenuhnya bertentangan dengan desain, mereka tidak akan mendapatkan indikasi (kecuali Anda, tetapi mereka tidak akan mendengarkan) bahwa apa yang mereka lakukan adalah bodoh, dan kemudian mereka Aku akan terkejut semua itu tidak bekerja seperti yang diharapkan.

1. Kurangnya Berbagi Informasi (pemrogram terbang sendiri atau dalam kelompok kecil - desainer mobil bekerja dengan tim yang saling berhubungan di dalam sebuah perusahaan besar, dan mereka semua berbagi pengetahuan mereka; jika kita semua bekerja untuk perusahaan besar, kita semua akan menjadi pemrogram yang lebih baik karena belajar dari yang lain; ini juga mengapa hal-hal seperti program sumber terbuka dan sumber daya online sangat penting)
2. Harapan dari Para Peserta Lapangan (tidak apa-apa jika seorang desainer mobil hanya berguna secara marginal untuk 5-10 tahun pertama, tetapi jika seorang programmer melakukan wawancara dan mengatakan dia tidak akan banyak berguna selama 5-10 tahun, wawancara selesai)
3. Kurangnya Pengujian Penetrasi (karena kurangnya dana, masalah legalitas, dll.; Pembuat mobil, bagaimanapun, membanting mobil demi mobil ke dinding bata, memiliki terowongan angin, memiliki persyaratan kinerja yang relatif mudah, dll.)
4. Transparansi Informasi (Anda tidak tahu cara kerja sebagian besar perangkat lunak; Anda menebak atau membuat asumsi berdasarkan wawancara, siaran pers, iklan, dll.; Dengan mobil, namun, sebagian besar hal ada di sana untuk Anda lihat)
5. Enkapsulasi Pengetahuan Inheren (lelaki / robot yang mengelas bingkai bersama-sama tidak perlu mengetahui matematika di balik sistem kontrol stabilitas; programmer harus memiliki pengetahuan tentang ribuan atau puluhan ribu hal yang tidak diketahui oleh orang kebanyakan, sedangkan desainer mobil hanya perlu tahu ratusan atau ribuan)
6. Tangibilitas (membantu ketika Anda bisa melihatnya)
7. Age of Field (desain kendaraan berumur ribuan tahun; desain kendaraan bermotor lebih dari 250 tahun [mesin uap, dll.))
8. Criticality of Subsystems (mobil masih akan "bekerja" bahkan jika banyak bagiannya berhenti bekerja - power lock, power windows, HVAC, wiper kaca depan, jendela pecah, dop roda hilang, ban kempes, pasang ban baru, radio, satu atau dua cahaya, entri jarak jauh, dll; ketika sesuatu pada komputer rusak, sering kali merupakan skenario SHTF)
9. Saling ketergantungan (ketika satu komputer rusak, tidak jarang mempengaruhi ratusan atau ribuan komputer lain; ketika satu mobil rusak, agak jarang mobil lain terpengaruh - jika mobil lain terpengaruh, hampir selalu hanya 1) -3)
10. Blanket Blame (jika satu bagian dari komputer atau satu komputer keluar dari ribuan kerusakan dan melukai sistem, kesalahan meluas ke seluruh komputer, atau dalam kasus terakhir, seluruh jaringan komputer; jika mobil Anda ditabrak oleh mobil dengan rem gagal, atau jika sebuah mobil berhenti dan tidak mau memulai kembali di jalan raya, hanya bagian mobil individu yang disalahkan)
11. Sistem terbatas hingga Infinite (mobil hanya dapat memiliki begitu banyak, dan mereka hanya diharapkan untuk bekerja dalam kondisi terbatas - misalnya Anda tidak mengendarai BMW di atas medan yang hanya dapat dilakukan oleh kendaraan seperti Jeep; dengan komputer, namun, kemungkinannya adalah de facto infinite - ada hal-hal baru sepanjang waktu, API baru, OS baru, lubang keamanan baru, iPad, perangkat lunak ponsel, ini baru, baru itu, dll.)
12. Lingkup Pengetahuan yang Diperlukan (orang dengan IQ 130-140 dapat mempelajari hampir semua yang perlu diketahui tentang mobil, tetapi hanya dapat mempelajari sebagian kecil dari apa yang perlu diketahui tentang komputer & pemrograman)

Alasan sederhana mengapa seluruh logika cacat:

Perangkat mekanis dapat direduksi menjadi Input / Output ; menambah jumlah bagian untuk mencapai operasi I / O ini tidak mengubah operasi I / O. Dengan demikian sistem dapat sepenuhnya dipahami.

Perangkat lunak di sisi lain memiliki Input -> Process -> Output . Karena sifat ini sistem tidak dapat sepenuhnya diprediksi atau dipahami.

Donald Rumsfeld mengatakan yang terbaik:

“Ada yang dikenal; ada hal-hal yang kita tahu kita tahu. Kita juga tahu ada yang diketahui tidak diketahui; artinya kita tahu ada beberapa hal yang tidak kita ketahui. Tapi ada juga yang tidak diketahui tidak diketahui - yang kita tidak tahu kita tidak tahu. ”- Sekretaris Pertahanan Amerika Serikat Donald Rumsfeld

Singkatnya:

• Perangkat mekanik adalah sistem yang telah dikenal, dan dikenal-tidak diketahui,
• Perangkat lunak memiliki di atas tetapi juga tidak diketahui-tidak diketahui.

Ini adalah pertanyaan bodoh (bukan dari Anda, tetapi dari orang asli).

Ini terdengar seperti ayah saya (seorang mekanik) yang membenci komputer namun menghabiskan sepanjang hari di eBay.

Itu seperti bertanya "Mengapa pohon lebih bisa diandalkan daripada ngengat?".

Pertama-tama, saya memiliki 30 (ya, 30+) komputer dan tidak satu pun di antaranya yang ada di toko. Saya hanya menghabiskan $ 1400 untuk perbaikan mobil saya. Pergi menghitung jumlah toko perbaikan mobil vs perbaikan komputer. Sekali lagi, analogi bodoh.

Mobil terbuat dari baja, plastik komputer. Mobil bekerja di segala kondisi cuaca, komputer dirancang untuk penggunaan dalam ruangan.

Commodore 64 saya (26 tahun) bekerja dengan sempurna dan tidak memiliki perbaikan. Kedua kendaraan saya (kurang dari 10 tahun) memiliki perbaikan yang sangat luas. Tunjukkan pada saya sebuah mobil dengan ribuan dan ribuan jam penggunaan yang berusia 26 tahun yang masih berjalan 100% sama seperti ketika pabrik baru.

Perangkat lunak didasarkan pada bit: 0 dan 1. Mobil didasarkan (sebagian besar) pada bagian mekanik.

Bagian mekanis dapat aus atau rusak dan masih berfungsi. Rem Anda aus, atau katup bocor, tetapi sebagian besar mobil masih berfungsi sampai Anda bisa memperbaikinya.

Perangkat lunak, sebagian besar, tidak memiliki kegagalan bertahap. Itu bekerja, atau rusak. Membagi dengan nol bukanlah "hampir benar"; itu hanya kesalahan. Ketika Anda mencoba menyimpan ke drive tanpa ruang yang cukup, Anda tidak dapat menekan dengan keras untuk memaksa semua data masuk; itu tidak akan pergi.

Saya tidak berpikir perangkat lunak tentu kurang dapat diandalkan daripada mobil, tetapi ketika perangkat lunak gagal, segera gagal, tidak secara bertahap.

Saya pikir saya punya analogi yang jauh lebih baik. Ambil perusahaan yang membangun ambulans sesuai spesifikasi pelanggan. Platform dasar (katakanlah, sasis RV-cutaway yang sepenuhnya operasional dan legal di jalan) memerlukan modifikasi di beberapa titik: kerangka, sistem pengisian, cerat pengisi, suspensi, dll. Modifikasi itu tidak hanya harus legal jalan tetapi memenuhi persyaratan yurisdiksi sementara memuaskan keinginan pelanggan.

Maka Anda harus membangun badan ambulans itu sendiri, yang juga penuh dengan persyaratan peraturan dari beberapa lapisan pemerintah dan badan-badan lain. Meskipun masih memuaskan keinginan pelanggan untuk pengaturan tempat duduk yang funky atau sistem penyimpanan. Dan jangan lupa bahwa Anda memiliki seratus pelanggan berbeda dari seluruh dunia dengan jadwal pembelian dan penempatan yang berbeda, tidak ada yang pernah mengatakan "Saya akan mengambil selusin lagi seperti yang terakhir" tanpa juga mengirimkan halaman pengecualian yang sering membutuhkan rekayasa ulang penuh dari semuanya.

Mobil? Itu sepele. Anda akan membeli apa yang dibangun dan Anda tidak memiliki dampak langsung pada aspek desain apa pun. Bahkan pilihan warna Anda adalah buatan karena Anda tidak dapat benar-benar menentukan sesuatu yang belum direkayasa dan diuji. Dalam arti tertentu hanya 'pasar' bukan 'pelanggan'. Saya berpendapat bahwa perangkat lunak yang diproduksi untuk beberapa pasar pada umumnya sama andal dengan mobil yang Anda ambil di dealer setempat.

Mobil sebenarnya tidak dapat diandalkan seperti yang Anda pikirkan. Hanya saja kesalahan bisa tetap tersembunyi untuk waktu yang lama (atau diabaikan) tanpa menyebabkan semuanya gagal. Oli dan / atau cairan pendingin mobil Anda? Tidak? Apakah kamu yakin Anda mungkin salah ... Itu mungkin hanya membocorkan jumlah yang sangat kecil di suatu tempat yang belum Anda perhatikan ... Sekarang memperluas itu ke suspensi, panel bodi, interior, dll. Saya tidak berpikir saya pernah belum menemukan mobil yang saya tidak dapat menemukan sesuatu yang salah. Namun, sebagian besar suku cadang tidak berguna untuk misi transportasi. Tidak demikian halnya dengan komputer. Hampir setiap bagian dalam komputer sangat penting.

Ini debat lama antara analog vs digital, baru saja dikemas ulang. TV digital bagus, asalkan semuanya sempurna. Sesuatu yang instan beres, gagap audio dan blok video membuatnya tidak berguna. Bandingkan dengan TV analog di mana Anda hanya akan mendapatkan desis atau statis yang mudah diabaikan.

Pertama tentu saja beberapa sw benar-benar dapat diandalkan, dan mobil - terutama yang Inggris dan Italia - tidak selalu dapat diandalkan.

Yang mengatakan pengalaman saya bekerja dengan perangkat lunak otomotif adalah bahwa ia datang ke dua hal:

• Biaya garansi. Ketika sw Anda gagal, Anda me-restart itu. Mungkin Anda akan mengajukan laporan bug. Atau gunakan kontrak dukungan yang mahal. Ketika mobil Anda rusak, Anda akan membawanya dan menuntutnya diperbaiki berdasarkan garansi. Ini akan dikenakan biaya pembuat $ 100 dan lebih tinggi. Jika setiap kegagalan sw membuat pembuat $ 2, saya yakin sw akan lebih andal.

• JD Powers (dan peringkat kualitas lainnya). JD Powers mensurvei ThingsGoneWrong (yang bisa berupa apa saja). Dan jika peringkat itu benar-benar buruk, orang tidak akan membeli mobil Anda, setidaknya tidak cukup uang untuk mendapat untung. Jika kami memiliki JD Powers untuk sw dan orang-orang benar-benar peduli, maka saya yakin sw akan lebih dapat diandalkan.

Jadi, jika Anda membuat mobil yang tidak bisa diandalkan, biaya garansi akan dengan cepat menghabiskan semua keuntungan Anda dan dalam beberapa tahun peringkat kualitas yang buruk berarti Anda tidak akan menjual mobil sama sekali. Jika Anda membuat sw tidak dapat diandalkan maka pengguna akan mengeluh dan Anda bisa menjual kontrak dukungan mahal.

Keamanan dan keandalan Kendaraan Bermotor adalah mandat. Di banyak negara (sebagian besar?) Diharuskan oleh hukum bahwa mereka memiliki tingkat keandalan dan keselamatan minimum dan mereka diuji untuk skenario terburuk (apa pun itu). Perangkat lunak komersial tidak, untuk sebagian besar.

Meskipun ada implikasi hukum lain untuk perangkat lunak, penting untuk dicatat bahwa jika perangkat lunak macet setiap kali Anda menekan tombol "Simpan", maka ini hanyalah masalah perbaikan / patch dan kemudian Anda terus berjalan. Jika mobil mogok setiap kali Anda menyalakan indikator, maka ini adalah hal yang jauh lebih buruk . Ini tidak begitu penting bagi Microsoft Outlook untuk berjalan tanpa menabrak secara tak terduga seperti halnya bagi SUV untuk menjalankan tanpa menabrak secara tak terduga.

Yang sedang berkata, ada bagian lain dari perangkat lunak yang memiliki tanggung jawab sebanyak atau lebih dari mekanisme mobil. Sistem Pesawat dan Panduan Rudal harus dapat diandalkan; ada nyawa yang dipertaruhkan! Orang akan berharap bahwa ini lebih teruji daripada mobil motor rata-rata.

Industri mobil tidak merilis mobil "beta" kepada publik untuk pengujian, industri mobil tidak perlu khawatir tentang lingkungan di mana mereka memberikan produk mereka, tetapi mereka saya harus khawatir tentang banyak hal lain. mengatakan bahwa industri perangkat lunak pada dasarnya berbeda (seperti kita ketahui), sehingga keandalan dan kompleksitasnya sangat sugestif. Menurut pendapat saya mobil sama rumitnya dengan perangkat lunak tetapi lebih mudah untuk melihat apa yang berfungsi atau tidak sejak saat itu

• Di bagian bawah mobil tidak virtual, pasti akan lebih mudah untuk diuji (tetapi lebih mahal)
• Mereka memulai jauh lebih awal daripada industri perangkat lunak, bahkan jika mereka lebih sedikit orang, Anda tidak dapat meminimalkan praktik dan pengetahuan yang mereka kumpulkan. Industri perangkat lunak masih bayi dibandingkan dengan itu.
• Semua industri mobil terikat oleh hukum dan etika untuk tidak membuat mobil yang membunuh pengemudi mereka terutama dekade terakhir.

Jadi pernyataan yang mengatakan bahwa perangkat lunak kurang dapat diandalkan daripada mobil, dapat berlaku untuk banyak jenis perangkat lunak dan sama sekali salah untuk bidang lain (keamanan, aeronautika ...) Anda dapat yakin bahwa suatu perangkat lunak setidaknya paling dapat diandalkan daripada yang paling dapat diandalkan mobil di daerah itu. Hanya karena area itu sangat penting dan dari apa yang saya tahu hanya di area itu perangkat lunak dapat dibandingkan dengan industri mobil.

Yang membawa kita ke ini: sebagian besar perangkat lunak tidak dianggap kritis dalam domain mereka. Ketika dianggap demikian, Anda memiliki perangkat lunak yang andal, satu-satunya masalah yang akan Anda temukan pada masalah tersebut adalah masalah yang terkait dengan lingkungan (jadi jika Anda dapat mengendalikannya, sebenarnya Anda tidak akan memiliki masalah), bukan perangkat lunak itu sendiri. Namun sebagian besar editor perangkat lunak tidak bekerja di area kritis ini, tentu saja mereka terikat untuk memberikan tingkat kualitas tertentu tetapi mereka lebih terikat (menurut saya) untuk memberikan perangkat lunak sesegera mungkin. Namun perangkat lunak yang baik membutuhkan: manajemen proyek yang baik, spesifikasi yang solid, desain yang baik, dan tingkat keterampilan yang baik dari mereka yang bekerja di dalamnya (untuk melanjutkannya). Itu hanya untuk membuatnya, kita bahkan tidak berbicara tentang menjualnya ...

Semua ini membutuhkan waktu dan membutuhkan uang. Saya tidak mengatakan Anda mendapatkan apa yang Anda bayar untuk apa yang saya katakan sebagian besar waktu Anda menghasilkan apa yang Anda investasikan dengan tidak pernah kurang (kecuali jika Anda kacau tapi kemudian Anda menghasilkan apa-apa begitu ...) dan kadang-kadang lebih. .

Saya tidak percaya mobil kurang kompleks. Tetapi bahkan jika itu masalahnya, saya tidak berpikir bahwa perangkat lunak kurang dapat diandalkan. Namun, saya percaya ada faktor yang lebih penting yang menyebabkan perbedaan dalam keandalan perangkat lunak:

1. Abstraksi yang terlibat dalam Perangkat Lunak. Hal ini menyebabkan pembuat perangkat lunak salah paham bagaimana hal-hal benar-benar berfungsi. Seiring berjalannya waktu, semakin banyak abstraksi yang ditambahkan. Misalnya, bahasa Assembly memberi Anda kendali langsung ke mesin. C lebih abstrak tetapi masih dekat dengan mesin. Java, C # dan apa yang akan terjadi selanjutnya sangat abstrak apa yang terjadi di mesin. Contoh lain adalah jika Anda seorang programmer yang ingin memahami bagaimana jaringan terjadi pada tingkat perangkat lunak, maka Anda harus tahu untuk memprogram dengan C karena infrastruktur (sebagai perangkat lunak) ditulis dalam C.

2. Pengalaman yang berbedadan Pengetahuan para pembuat mengarah ke hasil yang berbeda. Pengembang yang berbeda menciptakan perangkat lunak dengan keandalan yang berbeda. Hal yang sama dapat dikatakan tentang pembuat mobil. Namun, perbedaannya adalah siapa pun yang dapat menggunakan editor dan kompiler atau bahkan hanya menginstal IDE (Lingkungan Pengembangan Terpadu) dapat membuat perangkat lunak Dan gratis. Untuk membuat mobil, Anda memerlukan investasi besar, pabrik (beberapa dapat membuat mobil tanpa menggunakan tetapi Anda tidak akan menemukannya di mana-mana). Fakta bahwa Anda akan berinvestasi besar, berarti Anda akan mencoba untuk mempekerjakan yang terbaik di bidangnya. Namun, masih ada masalah keandalan dengan mobil. Jika Anda menyadarinya, jutaan mobil ditarik dari pasar karena masalah serius. Di mobil saya, pabrikan akan mengganti gunting rem secara gratis untuk semua mobil yang dibeli pada tahun yang sama.

3. Bug dalam perangkat lunak biasanya lebih tampak bagi pengguna daripada mobil. Ini adalah hasil dari interaktivitas dan respons antara pengguna dan perangkat lunak. Di dalam mobil, kita memperhatikan lebih sedikit perincian seperti "Mobil berakselerasi saat kita menginjak pedal gas", putus, belok, nyalakan, cermin, dll. Dalam perangkat lunak, dengan setiap klik / input pengguna biasanya ada sebuah tanggapan. Jadi, ada banyak titik di mana perangkat lunak dapat menjadi buggy dan pengguna akan segera melihatnya. Ini membuat pengguna percaya bahwa itu kurang dapat diandalkan daripada mobil.

4. Peretasan Dan Serangan . Semakin banyak perangkat lunak digunakan, semakin tinggi persentase serangan hacking. Anda dapat membandingkan ini dengan pencurian mobil. Bagi saya juga keandalan mobil terganggu ketika dapat dibuka oleh orang lain selain pemilik atau kunci. Namun, lebih mudah untuk mencoba menyerang perangkat lunak daripada mobil karena penyerang tidak terlihat. Jadi, ketika sebuah perangkat lunak dikompromikan, orang mengasosiasikan bahwa itu tidak dapat diandalkan meskipun itu dapat diandalkan untuk apa perangkat itu dibuat.

Ini seperti yang lainnya ... ketika berhasil Anda tidak peduli ... ketika itu rusak (atau tidak bekerja seperti yang Anda inginkan / harapkan), Anda peduli.

Pikirkan pesawat terbang. Banyak orang khawatir tentang orang yang mencoba membajak atau meledakkan mereka. Namun sebenarnya jumlah kejadian negatif sangat kecil dibandingkan dengan jumlah penerbangan harian. (Ada lebih banyak penerbangan dalam satu hari maka pernah dibajak atau dibom .. heck bahkan mencoba untuk dibajak atau dibom.)

Semuanya ada di situ Anda melihat dan bagaimana Anda mengukur.

Ini sebenarnya cukup sederhana. Mobil adalah teknologi tua. Tentu ada bel dan peluit akhir-akhir ini (istirahat itu) tetapi jika Anda melihat mobil awal - mereka banyak pecah .

'Teknologi' di belakang bagian mekanik mobil telah ada selama ratusan tahun dan mesin pembakaran internal telah ada sejak lama juga, dan ketika diperkenalkan, ada banyak masalah.

Pertimbangkan bahwa masalah memori hampir merupakan sesuatu dari masa lalu dengan beberapa platform terkelola kami. Berikan software beberapa ratus tahun dan kita akan mendapatkannya juga. Bahkan, mengingat kompleksitas perangkat lunak, saya pikir kita unggul.

Mobil modern mengandalkan s / w. Ketika mobil modern gagal, misalnya komputer mesin gagal, biasanya (walaupun tidak selalu, tetapi biasanya) elektronik yang mencatatnya, bukan s / w.

Tanyakan pada setiap pemilik mobil modern dengan ECU di dalamnya berapa lama mobilnya berjalan sebelum kegagalan yang mahal. Saya akan terkejut jika Anda mendapatkan 10 tahun. Mobil modern yang penuh dengan elektronik dan sensor sangat tidak dapat diandalkan.

Jika Anda mempelajari teori reliabilitas, jawabannya menjadi sangat jelas. Semuanya mekanik (perangkat lunak yang diharapkan) memiliki keandalan kondisi mapan yang merupakan tingkat kegagalan ketika berada di luar wilayah kematian bayi dan keausan. Tingkat kegagalan dari barang akhir adalah SUM dari tingkat kegagalan bagian. Tambahkan lebih banyak bagian: tingkat kegagalan agregat menjadi angka yang lebih tinggi. Tantangannya kemudian adalah untuk mendapatkan tingkat kegagalan dari semua komponen yang sangat rendah.

Ketika datang ke hal-hal seperti timing belt dan keausan silinder dan sensor oksigen menjadi penuh omong kosong, dan konektor menjadi ohmic, dan kabel putus karena getaran - ada teknik yang dapat digunakan untuk mengurangi tingkat kegagalan. Biaya juga naik saat Anda melakukan ini.

Perangkat lunak, di sisi lain, memiliki tingkat kegagalan yang konstan. Terlepas dari kesulitan menemukan cacat di kali, pada akhirnya semua perangkat lunak adalah mesin sosis. Input -> Lakukan barang -> Output. Terkadang ORDER input dan kombinasi input menyebabkan kegagalan dengan mode yang dapat dideteksi. Ketika itu terjadi, Anda telah menemukan cacat Anda, Anda memperbaikinya, dan Anda melanjutkan.

Perangkat lunak yang tidak memiliki cacat (diketahui) secara efektif memiliki tingkat kegagalan 0. Ini akan berjalan selamanya tanpa kegagalan. (Mean Time Between Failures = 1 / tingkat kegagalan). Platform perangkat keras akan gagal terlebih dahulu.

Perangkat lunak dengan cacat mungkin berjalan hanya sampai kombinasi kondisi input yang tepat, seiring waktu, menyebabkan cacat menjadi nyata.

FALLACY dalam semua ini adalah untuk mencoba dan membandingkan tingkat kegagalan benda-benda fisik (yang disebabkan oleh keausan, migrasi logam di IC, masuknya air, getaran, dll.) Dengan tingkat kegagalan dari apa yang pada dasarnya adalah mesin keadaan terbatas yang hanya melakukan dengan tepat apa yang diperintahkan oleh urutan instruksi itu untuk dilakukan.

(Bahkan hal-hal seperti partikel alfa yang membalik bit dalam RAM adalah fenomena fisik, bukan cacat perangkat lunak. Cara penanganan yang merata MUNGKIN namun menjadi cacat perangkat lunak, tetapi ingat, partikel alfa jahat itu hanyalah input lain ke dalam perangkat lunak. )

Perbedaan antara perangkat lunak dan mobil adalah bahwa agar pengembang perangkat lunak menjaga kewarasan, duplikat perangkat lunak yang tepat harus didorong oleh semua pengguna perangkat lunak dan agar produsen mobil dapat menjaga kewarasan, mereka harus menerima bahwa semua pengguna mereka akan mengemudi mobil yang sangat berbeda karena cara Anda mengendarai mobil mengubah mobil, tetapi cara Anda menggunakan perangkat lunak tidak selalu mengubah perangkat lunak.

Di samping itu,

Jika Anda memiliki beberapa cara untuk memeriksa minyak di perangkat lunak Anda, Anda akan tahu kapan itu akan gagal.

Jika Anda memiliki beberapa cara untuk mengganti oli dalam perangkat lunak Anda, Anda mungkin dapat memperpanjang masa pakainya dalam beberapa bulan.

Dan untuk memperpanjang analoginya:

Tambalan tidak mengganti oli, melainkan mengganti paking yang bocor.

Pembaruan tidak mengubah oli, mereka sedang memperbaiki rem.

Rilis tidak mengubah minyak, mereka lebih seperti menambahkan kunci kontak tanpa kunci.

Mobil yang mogok tidak dapat ditoleransi. Juga bisa membahayakan jiwa. Perangkat lunak yang mogok ditoleransi, dan pengguna bekerja di sekitarnya atau hanya menerimanya. Tidak ada banyak permintaan untuk perangkat lunak bebas bug.

Juga perangkat lunak cenderung disesuaikan, Anda tidak memiliki 10.000.000 model mobil yang berbeda. Saya akan mengatakan wikimedia dapat diandalkan dan banyak ppl menggunakan perangkat lunak itu. Jadi bisa dibilang banyak orang memang menggunakan bugfree atau software yang andal. (wordpress, berbagai kontrol sumber, mysql dan sqlite cukup dapat diandalkan, dll)

Perangkat lunak adalah objek matematika dan logika, sedangkan mobil adalah objek nyata.

Selain itu, Anda dapat dengan mudah mengetahui kapan mobil memiliki masalah dan apa masalahnya, sementara itu bisa jauh lebih sulit dengan perangkat lunak: bayangkan seseorang memiliki masalah dengan komputer dan seseorang yang memiliki masalah dengan mobil; orang ini bisa lebih tahu apa yang salah karena mobil kurang abstrak daripada komputer.

Saya tidak mengatakan komputer lebih sulit untuk dipahami: mobil juga melibatkan banyak hukum fisik seperti termodinamika, elektronik, kimia.

Anda juga dapat memperkirakan perbandingan ini, dengan mengatakan: "mengapa palu lebih dapat diandalkan daripada seorang sekretaris?".

Saya tidak berpikir pertanyaan itu benar-benar relevan, tetapi saya pikir itu menunjukkan dengan sangat baik bagaimana kurangnya pendidikan matematika yang baik dapat mempengaruhi pemahaman tentang jenis sistem tertentu.

Perangkat lunak jauh lebih kompleks daripada mobil, bahkan jika mobil itu terdiri dari ribuan komponen.

Jika sebuah mobil sama rumitnya dengan perangkat lunak, maka semua komponen mobil akan bergantung pada semua komponen mobil yang lain, dan banyak komponen mobil akan secara langsung dihubungkan dengan banyak komponen mobil lainnya.

Semua mobil di dunia nyaris tidak sama dengan perangkat lunak Unix asli dalam kompleksitas.