Get best of the week

Mengapa kita menulis program dengan kualitas buruk?


:
— , ,  — .
- :
— . .
:
— .
— ?
— . , .
— ?
— , , , , , .
- Mereka mengatakan bahwa keandalan dijamin oleh teknologi yang disebut blockchain.
- Ahhhhhhhh !!! Apapun yang mereka katakan, jangan menyentuhnya! Menggali lebih dalam. Jangan lupakan sarung tangan!
Sumber: lisensi XKCD , Creative Commons 2.5. Sebuah

kesalahan penghitungan seluler pekan lalu menambah kekacauan pada Kongres Partai Demokrat Iowa. Beberapa jam setelah pembukaan pertemuan di seluruh negara bagian, menjadi jelas bahwa ada sesuatu yang salah. Hasilnya masih belum diketahui. Ada pesan yang menjelaskan masalah teknis dan kesalahpahaman. Partai Demokrat Iowa mengeluarkan pernyataan yang menyangkal rumor tentang serangan cyber, tetapi mengkonfirmasi masalah teknis dengan aplikasi seluler.

Seminggu kemudian, kita sudah lebih memahami apa yang terjadi. Aplikasi seluler ditulis khusus untuk acara ini di Iowa. Itu didistribusikan sebagai versi beta , melewati direktori aplikasi besar. Pengguna menderita, tetapi berjuang untuk membuat program bekerja. Setelah instalasi, dia sangat mungkin tidak menanggapi panggilan. Di beberapa tempat pertemuan, tidak ada koneksi internet, yang membuat aplikasi online menjadi tidak berguna. Demokrat punya rencana cadangan: untuk melaporkan hasilnya melalui telepon, seperti biasa. Tetapi saluran telepon macet dengan troll online, yang membuat mereka macet demi lulz.

Twitter mengikuti gelombang tagar #app dan #masalah, sementara para insinyur perangkat lunak mengutip KDPV. Saya juga berpikir begitu. Kata-kata dari kartun ini dengan baik merangkum perasaan umum tentang apa yang terjadi: "Saya tidak cukup tahu bagaimana mengekspresikannya, tetapi seluruh area kami buruk dalam apa yang kami lakukan, dan jika Anda mengandalkan kami, maka semua orang akan mati." Insinyur perangkat lunak tidak mengatakannya secara langsung. Tapi kedengarannya sangat mirip. Apa yang kita maksud

Inilah yang kami maksud: kami melakukan perangkat lunak dengan baik, asalkan konsekuensi dari kegagalan tidak masalah. Rata-rata, program cukup baik untuk bekerja. Namun, kami tidak terlalu terkejut dengan kesalahan di sebagian besar program. Ini bukan insiden langka. Banyak praktik umum dalam rekayasa perangkat lunak berasal dari asumsi bahwa crash adalah norma, dan yang paling penting, fitur baru. Kegagalan benar-benar murah. Jika layanan online dari salah satu perusahaan terbesar benar-benar terputus selama dua jam, mereka akan melupakannya dalam seminggu. Asumsi ini diwujudkan dalam mantra umum: "Bergerak cepat dan hancurkan semuanya" (Bergerak cepat dan hancurkan benda-benda), "Gulir keluar dan ulangi siklus" (luncurkan dan ulangi).

Pasar dengan murah hati memberikan penghargaan atas perilaku "tidak bertanggung jawab" seperti itu. Di banyak perusahaan web, keuntungan kecil per pengguna dikalikan jutaan (atau milyaran!) Pengguna. Ini bermanfaat bagi perusahaan dengan aplikasi konsumen atau situs web. Implementasinya mahal, tetapi biayanya terbatas, dan distribusinya hampir gratis. Industri perangkat lunak konsumen telah menemukan kompromi: kami mengurangi tingkat implementasi hanya cukup untuk menjaga tingkat cacat kami cukup rendah, tetapi tidak terlalu banyak.

Kami menyebut pengembangan perangkat lunak semacam itu sebagai "model ekonomi situs web": ketika manfaat implementasi tinggi dan biaya coba ulang rendah, manajemen mendorong pelepasan fungsi kecepatan tinggi. Ini tercermin dalam praktik modern manajemen proyek dan implementasinya, yang akan saya bahas di bawah ini.

Tetapi, seperti yang saya katakan, "kami melakukan perangkat lunak dengan baik, asalkan konsekuensi dari kegagalan tidak masalah." Pendekatan ini menyebabkan kegagalan yang mengerikan jika konsekuensinya tidak murah, seperti di Iowa. Praktik umum pengembangan perangkat lunak telah tumbuh dari model ekonomi Internet, dan ketika asumsi model ini dilanggar, insinyur perangkat lunak melakukan pekerjaan yang buruk.

Bagaimana cara kerja pemrograman di perusahaan web?


Bayangkan perusahaan hipotetis QwertyCo. Ini adalah perusahaan perangkat lunak berorientasi konsumen yang menghasilkan $ 100 juta per tahun. Kami dapat memperkirakan ukuran QwertyCo dengan membandingkan dengan perusahaan lain. WP Engine, hosting WordPress, mencapai $ 100 juta ARR pada tahun 2018 . Blue Apron menghasilkan $ 667 juta untuk tahun itu . Jadi, QwertyCo adalah perusahaan menengah. Dia memiliki beberapa lusin hingga beberapa ratus insinyur dan dia tidak menerbitkan saham dalam sirkulasi publik.

Pertama, pertimbangkan ekonomi manajemen proyek di QwertyCo. Para pemimpin telah mengetahui bahwa Anda tidak ingin mengumumkan fitur baru secara instan. Anda memiliki kompromi antara kualitas perangkat lunak, tenggat waktu, dan kecepatan implementasi.

Seberapa pentingkah kualitas perangkat lunak bagi mereka? Tidak juga. Jika situs web QwertyCo tidak berfungsi selama 24 jam setahun, mereka memperkirakan kerugian hanya $ 273.972 (dengan asumsi bahwa waktu kerja secara linier berkorelasi dengan pendapatan). Mereka mengatakan bahwa situs tersebut sering offline selama 15 menit, dan tidak ada yang peduli. Jika fungsi tersebut membuat situs crash, mereka akan mengembalikannya dan mencoba lagi nanti. Upaya berulang itu murah.

Seberapa berhargakah fitur baru untuk QwertyCo? Berdasarkan pengamatan pribadi saya, satu bulan pekerjaan satu insinyur mampu mengubah pendapatan situs yang dioptimalkan dalam kisaran dari −2% menjadi 1%. Ini adalah kesempatan bulanan untuk mendapatkan $ 1 juta dari pendapatan QwertyCo tambahan untuk setiap insinyur. Metode seperti pengujian A / B bahkan mengurangi kesalahan: dalam beberapa minggu, Anda dapat mendeteksi perubahan negatif atau netral dan menghapus fitur-fitur ini. Karakteristik buruk itu murah - sifatnya aktif untuk waktu yang terbatas. Menang diperoleh selamanya. Bahkan persentase rendah dari taruhan menang membuat QwertyCo untung.

Mengingat pro dan kontra, kapan QwertyCo harus merilis suatu fungsi? Perhitungan ekonomi menunjukkan bahwa bahkan fungsi berisiko tinggi harus diluncurkan jika kadang-kadang menghasilkan untung. Oleh karena itu, setiap proyek berubah menjadi permainan optimisasi: "Berapa banyak yang dapat dilaksanakan pada tanggal ini?", "Berapa banyak waktu yang diperlukan untuk mengimplementasikan seluruh proyek? Bagaimana jika Anda menghapus X dari itu? Bagaimana jika Anda menghapus X dan Y? Bagaimana mempercepat implementasi bagian tertentu? ”

Sekarang pertimbangkan proyek perangkat lunak dari sudut pandang seorang insinyur perangkat lunak.

Sumber daya utamanya adalah waktu. Pengembangan perangkat lunak yang aman memakan waktu. Segera setelah produk melewati ambang kompleksitas tertentu, produk memiliki beberapa tahap pengembangan (bahkan jika produk tersebut tidak lulus sebagai bagian dari proses eksplisit). Mereka harus direncanakan dengan bantuan manajer produk. Produk diubah menjadi proyek atau rencana teknis, jika perlu, dibagi menjadi beberapa subtugas. Kemudian kode dengan tes ditulis, tinjauan kode dibuat, statistik dicatat, produk diintegrasikan dengan panel informasi dan peringatan. Jika perlu, pengujian manual dilakukan. Selain itu, pengkodean sering memiliki overhead tambahan yang dikenal sebagai refactoring.: Memodifikasi sistem yang ada untuk memfasilitasi implementasi fitur baru. Dalam implementasi fungsi "kecil", pengkodean itu sendiri hanya memakan waktu 10-30% dari waktu.

Bagaimana pengembang kehilangan waktu? Paling sering ini adalah kegagalan sistem. Selama downtime situs, semuanya termasuk dalam pekerjaan. Insinyur yang paling berpengalaman menghentikan proyek yang sedang berjalan untuk mengembalikan situs ke jalurnya. Tetapi waktu yang diambil untuk memadamkan api adalah saat ketika mereka tidak membawa manfaat tambahan bagi perusahaan. Proyek mereka terlambat. Bagaimana cara mengurangi downtime? Tes tertulis, pemantauan, pemberitahuan otomatis, dan pengujian manual semua mengurangi risiko peristiwa bencana.

Bagaimana lagi para insinyur kehilangan waktu? Melalui bug yang lebih halus dan langka. Beberapa kesalahan jarang muncul, tetapi menyebabkan kerusakan hebat. Mungkin pengguna kehilangan data jika mereka melakukan urutan tindakan tertentu. Ketika seorang insinyur menerima laporan kesalahan semacam itu, ia harus keluar dari segalanya dan memperbaikinya. Ini mengalihkan perhatian dari proyek saat ini, dan secara bertahap waktu downtime seperti itu dapat meningkat.

Dengan demikian, insinyur perangkat lunak yang berpengalaman mulai memperhatikan kualitas kode, mereka ingin memeriksanya dengan cermat. Itulah sebabnya organisasi teknik menggunakan metode yang tampaknya memperlambat kecepatan pengembangan: analisis kode, integrasi berkelanjutan, pengamatan, pemantauan, dll. Kesalahan lebih murah jika Anda menangkapnya pada tahap awal, sehingga insinyur berinvestasi besar dalam deteksi kesalahan awal . Mereka juga fokus pada refactoring, yang menyederhanakan implementasi. Dalam implementasi yang lebih sederhana, ada sedikit kemungkinan kesalahan.

Dengan demikian, manajemen dan pengembangan memiliki pandangan yang berlawanan tentang kualitas. Manual setuju dengan tingkat kesalahan tinggi (tetapi tidak terlalu tinggi), dan para insinyur ingin kesalahan menjadi minimum absolut.

Bagaimana ini mempengaruhi manajemen proyek? Manajer dan pengembang membagi proyek menjadi tugas-tugas kecil. Waktu tunggu proyek tergantung pada jumlah tugas dan jumlah insinyur. Paling sering, proyek membutuhkan terlalu banyak waktu - dan itu disesuaikan dengan menghapus fungsi. Kemudian para insinyur melakukan tugasnya. Realisasi tugas sering dilakukan di dalam sprint.. Jika waktu sprint adalah dua minggu, maka setiap tugas memiliki timer dua minggu implisit. Namun, tugas sering kali lebih lama dari yang Anda pikirkan. Para insinyur membuat keputusan penentuan prioritas yang sulit untuk diselesaikan tepat waktu: "Saya bisa melakukan ini pada akhir sprint jika saya menulis tes dasar dan jika saya melewatkan refactoring yang saya rencanakan." Sprint memberikan tekanan konstan, mendorong pengembang. Ini berarti bahwa insinyur dapat berkompromi pada kualitas, atau mengakui kegagalan pada pertemuan berikutnya.

Beberapa akan mengatakan bahwa saya terlalu keras pada sprint, dan mereka benar. Faktanya, semua ini adalah karena tekanan waktu. Proses sprint hanyalah cara yang mudah untuk meningkatkan tekanan ini dengan menerapkannya beberapa kali: sekali selama evaluasi seluruh proyek dan satu kali untuk setiap tugas. Jika produk dinilai pada nilai tambah bagi perusahaan, wajar jika waktu pelaksanaannya disesuaikan dengan sendirinya. Para insinyur juga tertarik dengan implementasi yang cepat, tetapi seringkali mencoba untuk mengoptimalkan biaya dalam jangka panjang, daripada dalam jangka pendek. Namun, banyak organisasi seringkali hanya merangsang kecepatan saat ini dalam jangka pendek.

Setelah menetapkan insentif seperti itu, manajer mendapatkan apa yang diinginkannya: ia dapat menyebutkan fungsi dan tanggal di masa depan, dan manajemen serta pengembang akan membahas bagaimana melakukannya. "Saya ingin Anda melakukan pembelian satu klik dalam dua bulan tanpa membuat akun." Manajer dan pengembang akan menulis semua tugas selama dua minggu dan akan mempersingkat daftar sampai mereka dapat meluncurkan fungsi yang disebut "pembelian satu klik". Dia akan memiliki risiko kegagalan yang sedang dan mungkin hanya akan bekerja setelah beberapa iterasi. Tetapi kegagalan itu bersifat sementara, dan fungsinya selamanya.

Apa yang terjadi jika asumsi model ekonomi seperti itu dilanggar?


Seperti yang saya katakan, kami melakukan perangkat lunak dengan baik, asalkan konsekuensi dari kegagalan tidak masalah. Ini ditunjukkan oleh slogan "Bergerak cepat dan hancurkan semuanya," "Gulir dan ulangi." Tetapi setiap orang dapat membayangkan situasi di mana pembuatan ulang itu mahal atau bahkan tidak mungkin. Dalam keadaan darurat, bangunan yang runtuh dapat membunuh ribuan orang dan menyebabkan kerusakan miliaran dolar. Kongres Fraksi Iowa tahun 2020 adalah contoh yang lebih ringan. Jika acara gagal, di malam hari semua orang akan pulang hidup-hidup. Tetapi partai tidak dapat mengatur pertemuan ini untuk kedua kalinya ... tanpa menghabiskan banyak waktu, uang dan usaha.

Catatan singkat: di bagian ini saya menggunakan frasa "berisiko tinggi" sebagai singkatan untuk "situasi dengan ketidakmungkinan mencoba kembali" dan "situasi dengan kemungkinan mencoba ulang yang mahal".

Apa yang terjadi ketika model situs ekonomi diterapkan dalam situasi berisiko tinggi? Mari kita ambil contoh secara acak: misalkan Anda sedang menulis aplikasi untuk melaporkan hasil pertemuan di Iowa. Langkah apa yang akan Anda ambil untuk menulis, menguji dan menguji aplikasi?

Pertama, rekayasa logistik: Anda harus menulis aplikasi Android dan iPhone. Pelaporan adalah persyaratan utama, sehingga server diperlukan. Aturan pengumpulan yang membingungkan harus disandikan baik pada klien dan di server. Sistem harus melaporkan hasilnya kepada pengguna akhir; ini adalah antarmuka lain yang perlu diprogram. Partai Demokrat mungkin memiliki persyaratan validasi dan pelaporan yang harus Anda tulis ke aplikasi. Selain itu, akan sangat tidak pantas jika server gagal selama rapat, jadi Anda perlu menerapkan beberapa jenis sistem pemantauan.

Selanjutnya, bagaimana cara memeriksa aplikasi? Salah satu opsi adalah pengujian pengguna. Anda menunjukkan gambar aplikasi hipotetis kepada pengguna potensial - dan mengajukan pertanyaan seperti "Menurut Anda apa yang dilakukan layar ini?" dan "Jika Anda ingin mendapatkan $ a_thing, di mana Anda akan mengklik?" Desain selalu memerlukan beberapa iterasi, jadi masuk akal untuk mengharapkan kualitas tinggi setelah beberapa putaran pengujian tersebut. Perusahaan besar sering menghabiskan beberapa putaran sebelum memperkenalkan fitur-fitur penting. Kadang-kadang mereka bahkan membatalkan fungsi setelah menerima umpan balik sebelum menulis setidaknya satu baris kode. Pengujian pengguna murah. Apakah sulit untuk menemukan lima orang yang akan menghabiskan 15 menit pada kuesioner, setelah menerima kartu hadiah untuk lima dolar sebagai hadiah? Dalam kasus kami, hal yang paling sulit adalah membuat sampel yang representatif,yang sesuai dengan perwakilan demokratis dari Iowa.

Maka Anda perlu memeriksa aplikasi dalam tindakan: instal dan konfigurasikan di smartphone Anda. Partai Demokrat harus memahami cara mendapatkan hasil. Jika terjadi kegagalan, Anda memerlukan paket cadangan. Tes yang baik dapat mencakup "pertemuan uji coba," di mana beberapa anggota Partai Demokrat Iowa mengunduh aplikasi dan melaporkan hasilnya ke server pusat pada tanggal tertentu. Ini akan mengidentifikasi masalah dan menguraikan situasi secara keseluruhan. Verifikasi dapat dilakukan secara bertahap ketika setiap bagian dari produk diperkenalkan.

Lebih jauh, Internet penuh dengan penjahat. Misalnya, kelompok-kelompok Rusia menyebarkan informasi yang salahmelalui media sosial seperti Facebook, Reddit dan Twitter. Karena itu, Anda perlu memastikan bahwa tidak ada orang asing yang mengintervensi. Bagaimana cara memeriksa keaslian hasil? Selain penjahat, Internet penuh dengan pelawak yang siap mengganggu acara apa pun hanya untuk bersenang-senang . Bagaimana sistem kami menahan serangan DDoS? Jika tidak, apakah ada paket cadangan? Siapa yang bertanggung jawab untuk memperkenalkan rencana cadangan dengan melaporkan ini di pertemuan? Apa yang terjadi jika akun anggota diretas? Jika perusahaan tidak memiliki pakar keamanan, kemungkinan aplikasi tersebut harus menjalani audit independen.

Selanjutnya, bagaimana Anda menjamin bahwa tidak ada kesalahan dalam perangkat lunak yang akan mendistorsi hasil? Oleh karena itu, Partai Demokrat harus curiga terhadap dirinya sendiri: apakah mungkin untuk percaya hasilnya jika ada pengkhianat di jajarannya? Hasil harus tersedia untuk verifikasi menggunakan salinan kertas.

Oke, mari kita berhenti mendaftarkan masalah. Satu hal yang jelas: dibutuhkan banyak waktu dan sumber daya untuk memastikan semuanya bekerja.

Pembuat aplikasi Iowa Caucus diberi $ 60.000 dan dua bulan. Mereka memiliki empat programmer. Jumlah ini tidak cukup untuk membayar empat programmer yang baik dan pengeluaran lainnya. Uang tidak dapat ditukar dengan waktu. Praktis tidak ada bantuan dari luar.

Bayangkan Anda menggunakan praktik yang diterima secara umum untuk menghapus tugas dari suatu proyek sampai garis waktu memungkinkan. Anda akan melakukan yang terbaik untuk menghemat waktu. Pratinjau untuk katalog aplikasi seringkali membutuhkan waktu kurang dari sehari, tetapi dalam kasus terburuk, itu bisa bertahan seminggu, dan aplikasi mungkin ditolak. Jadi mari kita lewati ini: Anggota Demokrat akan mengunduh aplikasi melalui tautan beta. Bahkan dengan pemeriksaan keamanan gratis, akan terlalu lama untuk memenuhi semua rekomendasi mereka. Karena itu, kami menolak pemeriksaan keamanan. Mungkin, selama pengembangan backend, Anda membayar desainer $ 1000 untuk membuat tata letak aplikasi dan logo. Anda merencanakan satu putaran pengujian pengguna (tetapi kemudian melewatkannya ketika tenggat waktu keluar).Gulir dengan cepat dan ulangi siklus! Semuanya selalu bisa diperbaiki.

Dan pemrograman selalu membutuhkan waktu lebih lama dari yang diharapkan! Anda akan menemukan busi. Pertama, aturan untuk mengadakan pertemuan tidak sepenuhnya jelas. Itu selalu muncul ketika solusi digital dikenakan pada dunia analog. Dunia nyata dapat menerima ambiguitas dan ketidakkonsistenan, tetapi dunia digital tidak dapat melakukannya. Menanggapi pertanyaan Anda, Komite Partai Demokrat akan menyiapkan klarifikasi. Ini akan menahan Anda. Komite juga dapat mengubah aturan pada detik terakhir. Ini akan menyebabkan Anda mengubah aplikasi tepat sebelum tenggat waktu. Selanjutnya, Anda memiliki beberapa pengembang, yang berarti overhead koordinasi. Apakah setiap encoder 100% berpengalaman dalam ponsel,dan dalam pengembangan server? Apakah mereka semua menguasai Bereaksi Asli dengan sempurna? Js? Naskah? Komunikasi server-klien? Kerangka kerja dan perpustakaan mana yang Anda pilih? Setiap “Tidak” menambah waktu pengembangan untuk memperhitungkan koordinasi dan pelatihan akun. Apakah semua orang senang dengan kerangka kerja pengujian yang Anda gunakan? Hanya bercanda. Tes apa yang ada ... Ya, pada awalnya mereka menulis beberapa tes, tetapi aplikasi berubah sangat cepat sehingga mereka dihapus.

Waktu tidak menunggu. Dua bulan telah kedaluwarsa - Anda mencapai garis finish dengan upaya terakhir dan merilis rilis final.

Berdasarkan model ekonomi dari suatu situs web, penyelesaian dengan tergesa-gesa adalah baik. Pada akhirnya, terburu-buru tidak masalah, karena Anda melewati garis finish! Semua masalah dapat diselesaikan dalam beberapa minggu, dan kemudian beralih ke proyek berikutnya.

Namun terburu-buru tercermin dalam Majelis Demokratik Iowa. Selama acara, panggilan mulai tiba dengan keluhan tentang aplikasi. Secara teoritis, hasil yang mustahil atau duplikat mulai muncul. Segera, programmer menyenangkan dengan senang hati menerbitkan foto-foto dari KDPV dan mengatakan bahwa Kongres Fraksi di Iowa seharusnya tidak memesan aplikasi sama sekali, dan bahwa pemungutan suara hanya dapat dipercaya dengan teknologi kertas.

temuan


Esai ini membantu saya secara pribadi untuk menyimpulkan: ketika merencanakan sebuah proyek, perlu untuk memformalkan biaya perubahan. Saya telah melakukan ini secara intuitif di masa lalu, tetapi harus dikonkretkan secara konkret. Formalisasi semacam itu membantu untuk memahami tugas-tugas apa yang tidak dapat gagal dalam kasus apa pun. Sepertinya itu ada di robotika seluler saya: ada siklus implementasi yang panjang, dan kerusakan dari malfungsi bisa menembus atap. Kami menghabiskan banyak waktu mengembangkan pemantauan dan menciptakan metode yang dapat diandalkan untuk menekan dan menghentikan sistem di luar kendali. Saya juga telah bekerja dengan layanan web konsumen selama sepuluh tahun, di mana konsekuensi dari kegagalan lebih rendah. Ada keinginan yang lebih tinggi untuk mengambil hutang jangka pendek dan bergerak maju dengan risiko kegagalan sementara, terutama ketika rollback murah dan kehilangan data tidak mungkin terjadi. Paling tidak, rangsangan mendorong untuk perilaku seperti itu.Ada teknik khusus di industri kami untuk mencegah masalah seperti itu. Salah satu diantara mereka -investigasi kegagalan imajiner (pra-mortem). Anda perlu melakukan ini lebih sering.

Kegagalan Iowa memiliki hasil positif. Beberapa yang tidak terkait dengan IT menyadari bahwa ada kesalahan dalam program. Di tahun-tahun mendatang, sponsor pengembangan aplikasi untuk partai politik akan mulai bertanya: "Apa yang menjamin bahwa situasi dengan Kongres fraksi di Iowa tidak akan terulang?" Mungkin mereka akan berkenalan dengan literatur, yang mencoba mengajarkan manajer bagaimana bekerja dengan baik dengan insinyur. Sebagai contoh, Departemen Pertahanan AS memiliki panduan yang disebut "Bagaimana Mengenali Proyek Palsu Agile," yang menggambarkan tanda-tanda yang mencurigakan tentang kontrak. Forum untuk startup penuh dengan non-teknisi yang meminta (dan mendapatkan) nasihat tentang mempekerjakan pengembang.

Industri TI belum mempelajari apa pun. Kongres Fraksi Iowa memberikan kesempatan untuk memeriksa bagaimana asumsi "biaya kesalahan tinggi" akan mengubah proses inti kami. Tetapi kami tidak mengambil kesempatan ini dan tidak mengambil apa pun darinya. Industri perangkat lunak konsumen tidak memperhatikan risiko kesalahan. Bahkan, kami bahkan senang dengan kesalahannya. Jika dunia luar tertarik untuk meningkatkan kualitas kode kita di area tertentu, maka mereka harus mengatur area ini. Ini bukan pertama kalinya. Hukum Sarbanes - Oxley dan HIPAA adalah contoh regulasi dalam pengembangan model ekonomi situs web. Regulasi tidak cukup, tetapi mungkin ternyata perlu.

Inilah yang kami maksud ketika kami mengatakan: "Saya tidak tahu bagaimana mengekspresikannya, tetapi seluruh area kami buruk dalam apa yang kami lakukan, dan jika Anda mengandalkan kami, maka semua orang akan mati." Industri kami dibentuk di lingkungan yang kemundurannya murah. Dan kami tertarik pada kemajuan yang cepat. Jika perubahan itu tidak mungkin atau terlalu mahal, maka proses biasa kita bekerja dengan buruk.

More articles:


All Articles