Realitas Tidak Pernah Belajar Cara Mengembangkan Perangkat Lunak Berkualitas Tinggi

• Banyak proyek menunda langkah-langkah QA hingga belakang dan bergantung pada sprint QA besar tepat sebelum rilis, lalu mengulangi kekacauan yang sama pada siklus berikutnya
• Pendidikan ilmu komputer menghabiskan waktu pada algoritme, bahasa, dan manajemen proyek, tetapi sering tidak membahas jaminan kualitas perangkat lunak pada tingkat praktik kerja nyata
• Di perusahaan, saat anggaran kurang, pengembangan terlambat, atau cakupan bertambah, QA sering menjadi hal pertama yang dikurangi, sehingga perangkat lunak yang rapuh dirilis hanya setelah pengujian minimal yang tidak terstruktur
• Untuk meyakinkan soal QA, lebih baik berbicara tentang biaya jika hal itu tidak dilakukan dalam bentuk kenaikan biaya pengembangan atau bertambahnya masa stabilisasi rilis, daripada memakai ungkapan abstrak seperti “lebih stabil”
• Daripada membangun seluruh sistem kualitas sekaligus, lebih realistis melindungi fitur inti yang langsung terhubung dengan nilai pelanggan terlebih dahulu, dan menulis pengujian untuk fitur baru saat fitur itu diimplementasikan

---

QA yang terus terdorong sampai tepat sebelum rilis

• Di banyak proyek, pengembangan berjalan tanpa langkah-langkah jaminan kualitas penting
• Meski semua tahu itu perlu, pelaksanaannya sering menumpuk menjadi sprint QA besar tepat sebelum rilis
• Cara ini menambah stres dan hanya membuat perangkat lunak sekadar sampai bisa berjalan
• Pada siklus rilis berikutnya, kekacauan yang sama terulang lagi dan sulit berujung pada perbaikan yang terstruktur

Kesenjangan kualitas antara pendidikan dan praktik kerja

• Program ilmu komputer terutama berfokus pada algoritme, cara kerja komputer, serta sejarah dan konsep bahasa
• Mungkin ada satu semester yang mengajarkan metode manajemen proyek atau Scrum, tetapi QA bisa sepenuhnya tidak dibahas
• Karena lebih dari 90% lulusan akan bekerja dalam konteks perusahaan, mereka perlu mampu mengirimkan perangkat lunak bebas bug dalam waktu yang ditentukan
• Mengabaikan QA dalam pendidikan tidak selaras dengan tuntutan pekerjaan nyata

Struktur yang membuat QA jadi yang pertama dikurangi di perusahaan

• Saat muncul masalah anggaran dalam proyek, standar dan langkah QA sering menjadi hal pertama yang dikeluarkan
• QA sering ditempatkan di akhir proyek, jadi ketika pengembangan memanjang atau cakupan bertambah, waktu untuk memastikan kualitas menjadi tidak cukup
• Akibatnya, perangkat lunak dengan struktur rapuh dirilis setelah hanya menjalani pengujian minimal yang tidak terstruktur
• Beberapa tim memang punya standar QA, tetapi biasanya dalam bentuk anggota tim senior yang memaksakannya kepada anggota lain
• Bahkan jika standar ada, bila tim menulis pengujian hanya untuk memenuhi metrik manajemen proyek, hasilnya tetap sulit menjadi jaminan kualitas yang memadai

Langkah pertama untuk memutus masalah kualitas yang berulang

• Menunjukkan bahwa langkah QA belum ada membutuhkan pengalaman dan kepercayaan diri
• Crunch menjelang rilis, sistem produksi yang bermasalah, dan monitoring yang kurang pada akhirnya menjadi beban seluruh tim
• Perbaikan yang tidak terlihat langsung oleh manajer, seperti refactoring, memang sulit dijual, dan QA bisa terasa lebih membingungkan jika belum pernah dilakukan dengan benar
• Langkah pertama baru bisa tercipta jika masalah itu terus diangkat dan diskusinya dibuka kembali berulang kali

Menjelaskan QA dengan bahasa uang

• Kalimat seperti “perangkat lunak akan menjadi lebih stabil” atau “akan lebih mudah dipelihara” sulit terasa konkret bagi orang yang tidak bekerja langsung dengan codebase
• Pengembang perlu membicarakan biaya dari tidak melakukan QA
• Contoh ungkapannya seperti berikut
  • Jika tidak dilakukan sekarang, empat bulan lagi upaya dan biaya pengembangan akan naik 15%
  • Jika unit test tidak ditambahkan ke semua fitur, tahap stabilisasi rilis akan makin panjang setiap kali
  • Semakin banyak fitur baru, semakin banyak efek samping yang harus diuji manual setiap saat, sehingga kemajuan pada tiap rilis menurun
• Cara seperti ini lebih mudah dipahami oleh bisnis dan manajer
• Pada akhirnya, langkah QA bisa membuat hidup pengembang maupun manajer menjadi lebih baik

Memulai dengan minimum effective dose

• Jika QA dirancang berlebihan sebagai investasi awal yang besar, proyek bisa terhambat dan sulit mendapat persetujuan para pemangku kepentingan
• Titik awal yang realistis adalah menemukan bagian paling penting dari aplikasi
• Biasanya ada use case, fitur, atau perilaku inti tertentu yang menjadi sandaran seluruh aplikasi
• Yang perlu diuji terlebih dahulu adalah fitur inti yang harus bekerja benar agar pelanggan menerima nilai
• Minimum effective dose (MED) berarti dosis terkecil yang menghasilkan hasil yang diinginkan
• Dalam QA, MED bisa berupa salah satu dari berikut
  • rencana pengujian manual
  • pengujian otomatis di pipeline
  • langkah lain untuk menjamin perilaku inti
• Setelah fitur inti terjamin, cakupan stabilitas bisa diperluas secara bertahap
• Untuk setiap fitur baru, tambahkan unit test, dan verifikasi juga informasi yang tidak bisa dikendalikan seperti API eksternal atau input pengguna
• QA juga perlu ditingkatkan secara berulang dan bertahap

Pertanyaan QA yang perlu dicek pada proyek baru

• Saat memulai atau bergabung dengan proyek baru, perlu dipastikan apakah ada konsep QA walaupun dalam bentuk kecil
• Tim perlu memikirkan pertanyaan berikut
  • Apa yang kita rilis
  • Apa yang harus pasti berfungsi
  • Bagaimana kita menjaminnya
  • Langkah apa yang sengaja tidak kita lakukan, dan mengapa
• Jika hal-hal ini didokumentasikan dan ditambah dengan rencana pengujian, itu menjadi fondasi yang baik agar perangkat lunak bisa berkembang
• Pendekatan yang dipilih sebaiknya ditinjau secara berkala, misalnya setiap kuartal

Menulis pengujian bersama implementasi

• Bahkan jika tidak memakai TDD, tetap disarankan menulis pengujian sambil menulis perangkat lunak
• Saat sebuah fitur diimplementasikan adalah waktu yang tepat untuk menulis pengujian
• Menulis pengujian bersamaan dengan implementasi memaksa kode tersusun agar benar-benar bisa diuji
• Jika pengujian baru ditempelkan belakangan pada perangkat lunak yang sudah ada, sering kali baru terlihat bahwa kode terlalu saling bergantung atau melanggar prinsip tanggung jawab tunggal
• Pengujian menjadi penjelasan bahwa perilaku yang diinginkan telah dipahami dan diverifikasi berjalan sesuai harapan, sekaligus berfungsi sebagai bentuk dokumentasi kode

Dampak yang kembali ke proyek dan individu

• Jika Anda mengangkat diskusi tentang kualitas dan mengusulkan solusi yang memungkinkan, orang sekitar akan melihat bahwa Anda peduli pada proyek
• Diskusi kualitas dapat memperluas ruang pengaruh Anda sebagai pengembang
• Kualitas hidup pengembang dan manajer juga bisa meningkat
• Proyek dapat tumbuh dengan kecepatan yang sehat ketika ada langkah-langkah QA
• Tidak semua orang harus menjadi duta QA, tetapi Anda bisa mulai dari MED kecil dan menunjukkan cara yang lebih baik di dalam tim

[GN⁺]

Opini Hacker News

• Hal-hal seperti ini sebenarnya diajarkan. Hanya saja bukan di mata kuliah inti ilmu komputer, melainkan di mata kuliah pilihan seperti rekayasa perangkat lunak
  Di CMU juga ada program magister dan doktoral rekayasa perangkat lunak, yang membahas hal-hal yang disebutkan dalam tulisan blog itu dan lebih jauh lagi. Memang ada jurang besar antara CS dan SE, tetapi tidak sampai pada level “tidak ada yang mengajarkan cara membuat perangkat lunak berkualitas baik”

  • Di program sarjana CS di Swedia, saya mempelajari hal-hal seperti ini, dan saya rasa alasan saya praktis menjadi tech lead dalam setahun di pekerjaan pertama bukan karena bakat luar biasa bawaan, melainkan karena saya belajar rekayasa perangkat lunak
    Ironisnya, saat masih mahasiswa, mata kuliah rekayasa perangkat lunak adalah yang paling saya benci. Kelas design pattern yang kaku mengikuti UML terasa usang, dan kelas QA yang mengajarkan TDD serta tooling di ekosistem Java juga membosankan. Beberapa tahun kemudian, ketika saya bergabung dengan tim yang membangun workflow dan tooling pengujian untuk perangkat lunak dengan persyaratan keamanan tinggi, rekan-rekan saya terkejut karena saya sudah tahu apa saja yang harus dilakukan
  • Ada perbedaan besar antara diajarkan di CMU dan diajarkan di kebanyakan universitas
    Kalaupun diajarkan, biasanya materinya sudah usang atau terlalu harfiah seperti menulis aplikasi web. Kalau ada kelas yang berfokus pada implementasi, kerja tim, dan membangun sistem kompleks, saya benar-benar ingin mengambilnya
  • 90% lulusan CS akhirnya bekerja bukan sebagai ilmuwan komputer, melainkan sebagai software engineer
    Hal seperti ini seharusnya bukan ditempatkan sebagai mata kuliah pilihan atau program magister; yang dibutuhkan adalah program sarjana rekayasa perangkat lunak, dan 90% mahasiswa CS sebaiknya pindah ke sana
  • Seorang teman selama bertahun-tahun mencoba membuat mata kuliah rekayasa perangkat lunak di jurusan tempat ia bekerja sebagai pengajar. Rencana kuliah dasarnya adalah menerima handover dan codebase dari semester sebelumnya, mengimplementasikan fitur baru, melakukan deploy dan operasi, lalu menulis handover untuk semester berikutnya
    Codebase-nya berupa layanan sederhana yang menyediakan pemindaian virus/malware, dan dirancang agar selalu ada pekerjaan tambahan, termasuk scanner dan signature. Itu ide lebih dari 15 tahun lalu, tetapi bisa menjadi kelas bagus yang berkelanjutan; sayang ia tidak berhasil meyakinkan jurusannya
  • Kalau teman-teman saya tidak menceritakan pengalaman buruk mereka di kelas compiler dengan begitu gamblang, saya mungkin tidak akan mengambil kelas distributed computing sebagai pilihan lain untuk mengisi kategori itu
    Mungkin bukan kelas yang sepenuhnya mendefinisikan masa sarjana saya, tetapi cukup dekat; fakta bahwa kebanyakan orang yang merancang sistem tidak mengetahui materi ini membuat saya sekaligus marah dan mengalami semacam ketakutan eksistensial

• Alasan lebih mudah bekerja dengan orang yang punya gelar CS adalah karena kita lebih jarang perlu meyakinkan mereka tentang perlunya algoritma yang baik atau bahwa mereka sebaiknya tidak mengimplementasikan parser dan kriptografi sendiri
  Sebaliknya, di sisi rekayasa perangkat lunak, tidak ada kredensial yang bisa membuat kita percaya bahwa kenaifan tentang kualitas, kerja tim, dan kolaborasi dengan tim lain sudah diasah dengan cara serupa. Ada orang-orang yang terbentuk oleh pengalaman menulis kode buruk yang tidak teruji dengan cepat lalu pergi sebelum masalah meledak; manajemen menyukai orang-orang seperti itu dan meremehkan orang yang tertinggal untuk membersihkan puing-puingnya

  • Sudut pandang yang menarik. Saya menyelesaikan sekitar 95% program magister CS sebelum keluar untuk membangun startup, dan meski saya tahu nilai parser generator, sering kali menulis parser sederhana sendiri itu tepat, berguna, dan lebih cepat
    Protokol berbasis string dengan delimiter yang jelas biasanya sangat mudah di-parse, dan tergantung use case, cukup menangani sebagian saja. Tentu saja pengujian dan kebutuhan fitur tetap harus dipertimbangkan. Kalau sedang membuat bahasa pemrograman, sarannya bisa berbeda
  • Untuk kriptografi memang benar, tetapi saya ragu apakah parser juga begitu. Di sini tampaknya ada semacam kurva U
    Pemula membuat sendiri, developer tingkat menengah dan proyek skala menengah memakai parser generator, sementara orang-orang yang memelihara parser paling canggih juga cenderung memilih menulisnya sendiri. GCC dulu memakai parser bison, tetapi beralih ke parser recursive descent yang ditulis tangan demi pesan error yang lebih baik, dan Clang juga memakai recursive descent
  • Saya punya sanggahan soal parser. Karena sangat sulit menyediakan pesan error diagnostik yang berguna dengan yacc/bison, kebanyakan bahasa akhirnya memakai parser recursive descent yang ditulis tangan
    Satu-satunya pengecualian yang saya tahu secara pribadi adalah jq, dan karena itu di implementasi jq sulit membuat pesan kesalahan sintaks yang berguna
  • Kriptografi dan parser tidak seharusnya dimasukkan dalam kalimat yang sama. Tidak pernah ada momen yang tepat untuk menulis kriptografi sendiri, tetapi cukup banyak proyek compiler/interpreter besar memakai parser yang ditulis tangan, dan sering kali bahkan menulis lexer sendiri
    Menulis parser bisa cukup sederhana untuk dimasukkan dalam satu tugas kuliah, dan kode parser yang ditulis tangan pada akhirnya mirip dengan grammar LL. Parsing adalah bagian paling mudah dalam menulis compiler atau tooling bahasa, jadi jika parser yang ditulis sendiri menjadi standar yang terlalu tinggi bagi sebuah tim, keseluruhan proyeknya patut dipertanyakan. Bukan berarti parser generator tidak boleh dipakai sama sekali, tetapi saya lebih ingin bekerja di proyek yang punya parser tulisan tangan yang teruji baik daripada proyek yang memperumit build dengan tooling tambahan atau memakai tool lama seperti Bison/ANTLR
  • Ini masalah budaya. Sebaiknya hindari organisasi pengembangan bergaya koboi
    Meski begitu, standar secara umum tampaknya sudah lebih tinggi dibanding 20 tahun lalu. Misalnya, source control, unit test, dan CI/CD tidak lagi kontroversial

• Premis bahwa “kita harus mengirimkan software tanpa bug tepat waktu” adalah titik awal yang cukup buruk untuk memulai tulisan tentang software berkualitas
  Jika Anda percaya bisa merilis kode tanpa bug, sudah waktunya berganti profesi

  • Jika Anda pernah menulis software level operasional di perusahaan nyata, Anda harus menerima bahwa begitu membuat commit baru, bahkan perubahan 1 baris pun bisa merusak sesuatu
    Meski sudah melakukan unit test, integration test, dan user acceptance test, satu perubahan kode tetap berarti kemungkinan bug baru. Kalau seorang developer berkata, “Saya tidak pernah merilis kode yang mengandung bug,” kita jadi ingin menggali lebih jauh apa maksudnya
  • Sayangnya, itu benar. Merilis tepat waktu dan bebas bug berbanding terbalik, dan di dunia yang sulit meminta waktu untuk pengujian yang lebih baik atau pelunasan utang teknis kepada PM, itu memang realitasnya
  • Kebijaksanaan semacam ini tampaknya datang dari pengalaman atau cara berpikir yang lebih tinggi. Seperti yang dikatakan tulisan itu, kebanyakan testing/TDD/QA ditambahkan belakangan atau ditumpuk di akhir sebagai “sprint QA”
    Begitu melewati tahap “menulis fungsi”, “menguji fungsi”, dan “menguji sampai fungsi yang dipanggil lewat jaringan”, Anda akan sadar bahwa sebaik apa pun menangani kondisi batas dan seteliti apa pun QA, pada konfigurasi tertentu, hardware tertentu, kernel tertentu, selalu ada perilaku tak terdefinisi 0-day yang tersisa. Kita hanya bisa mengatakan bahwa karena sudah lolos testing, mata manusia, dan review, hampir tidak ada bug yang bisa dijamin; pada akhirnya kita cuma bisa berharap
  • Ini pandangan yang cukup pedas tentang rekayasa. Saya bertanya-tanya mengapa di software kita menerima hal-hal yang tidak akan diterima di bidang rekayasa lain
  • Jika biaya memperbaiki bug lebih besar daripada dampaknya terhadap pengalaman pengguna atau pekerjaan yang harus dilakukan, bug yang bocor ke produksi bisa sepenuhnya diterima
    Kalau butuh seminggu untuk diperbaiki tetapi hanya ditemui segelintir pengguna dalam situasi yang sangat langka, bug itu mungkin tidak perlu diperbaiki

• Ada juga program ilmu komputer, dan ada universitas yang menekankan internship serta praktik. Namun banyak jurusan CS di universitas berasal dari departemen matematika dan berpusat pada teori
  Menurut saya ini tidak masalah, sebagaimana kimia bukanlah teknik kimia. Universitas bukan sekadar sekolah vokasi, dan tujuan hampir semua gelar adalah melatih kemampuan berpikir serta menunjukkan kemampuan mempelajari materi yang kompleks

  • Masyarakat membutuhkan campuran sekolah vokasi dan universitas tradisional. Jika universitas tidak menyediakan keduanya, itu berarti gagal bagi semua orang
    Pendidikan universitas murni yang tidak mempertimbangkan kegunaannya di dunia nyata merusak pendidikan, tetapi pendidikan vokasi murni yang hanya mengajarkan cara tanpa pemahaman juga tidak berguna. Meski begitu, sekolah vokasi nyata pun tidak sepenuhnya seperti itu; walau mungkin melewati bagian yang sulit, mereka cenderung memberikan pemahaman mendalam tentang hal-hal penting
  • Bahkan dalam internship seperti itu, yang dipelajari bukan cara membuat software berkualitas, melainkan cara merilis SPA yang terhubung ke API dalam 15 minggu. Kalau tidak bisa, Anda tidak direkrut
    Meski begitu, itu bagus untuk mengintip dunia software profesional

• Hal seperti ini dipelajari di organisasi pengembangan yang baik. Sekitar 10–15 tahun lalu, kira-kira FAANG seperti itu; sekarang contohnya tempat seperti TailScale
  Kita bisa menghindari tumpukan microservice dan Docker yang tidak perlu, lapisan serialisasi/deserialisasi JSON, serta sekadar banyak unit test demi coverage sambil mengabaikan QuickCheck, Hypothesis, dan fuzzing. Semua mungkin dilakukan: kumpulan perubahan bertumpuk, rotasi on-call untuk tim yang menulis kode, meminimalkan dynamic linking dan error dependensi yang tidak dipaksakan, desain yang sesuai dengan runtime bahasa terkelola, sampai menuntut tata bahasa lisan yang mudah dibaca dalam suatu bahasa sebagai “keterbacaan”. Meski berulang kali diabaikan, cara merilis software berkualitas adalah pengetahuan publik

  • Saya tidak tahu apa maksud “kira-kira FAANG”, dan saya juga bertanya-tanya apakah “hari ini TailScale” maksudnya VPN itu
    Mungkin ada pemikiran tentang software berkualitas, tetapi komentar ini sulit dipahami
  • Masalah dominannya tampaknya software berkualitas baik sering kali tidak mengalahkan software yang berantakan dari sisi pendapatan
  • Saya ingin tahu saran tentang bagaimana menemukan organisasi bagus dan pengetahuan kualitas seperti ini
    Saya juga ingin tahu apa yang harus dilihat, serta apakah ada buku atau kuliah yang direkomendasikan

• Sulit mencapai metrik yang cukup valid untuk mendukung klaim seperti “jika tidak dilakukan sekarang, upaya dan biaya pengembangan akan meningkat 15% empat bulan lagi”
  Di sebuah startup, pernah ada dua founder yang berkata “jangan tulis unit test.” Saya tidak berdebat, dan saya paham makna sebenarnya adalah kami terlalu lambat, jadi rilis secepat mungkin. Kami rilis cepat, tetap menjaga kualitas, dan tetap menulis unit test. Mereka tidak perlu tahu; mereka hanya butuh hasil. Inti tersembunyi dari diskusi seperti ini adalah bahwa sebagian besar organisasi software tidak tahu cara merilis dengan cepat sekaligus berkualitas. Tidak ada formula ajaib; dibutuhkan craftsmanship individu dan ini juga olahraga tim. Situasinya berbeda di setiap tempat, jadi proses ringan mungkin berhasil sebagian, tetapi efeknya terbatas. Pada akhirnya, yang dibutuhkan adalah tim bagus dengan pengalaman, nilai yang benar, dan kebijaksanaan untuk berfokus pada penyampaian nilai

• Premis bahwa universitas mengajarkan cara membuat software di industri adalah klaim yang cukup berani
  Selain itu, tulisan ini terlihat seperti tulisan dari tahun 90-an ketika software didistribusikan lewat CD atau floppy disk. Saat ini, karena pipeline continuous deployment, konsep “rilis” sering menjadi kabur, dan ini dianggap praktik yang baik. Dalam situasi seperti ini, gagasan bahwa departemen QA secara manual menjamin tidak ada bug dalam rilis terasa sangat usang

  • Tidak semua orang menulis web app yang bisa di-upgrade kapan saja begitu CI lulus, atau aplikasi ponsel yang bisa diperbarui tiap minggu
    Ada juga orang yang membuat kode yang dikirimkan pada perangkat yang sulit di-upgrade
  • Ini mengingatkan pada kasus seperti Boeing. Seperti cerita bahwa 737 Max diuji oleh kontraktor murah di India, ada sangat banyak software yang tidak memiliki continuous deployment

• Jika Anda membutuhkan persetujuan seseorang, Anda harus menjelaskan kepada orang itu mengapa itu ide yang baik
  Pernyataan seperti “ini lebih stabil” atau “akan lebih mudah dipelihara” tidak terasa relevan bagi orang yang tidak bekerja langsung di codebase. Developer harus berbicara dalam biaya ketika QA tidak dilakukan, yaitu dalam bahasa uang. Meski “tapi ini kan cara yang benar!” terasa seperti argumen yang tak terbantahkan, orang yang memberi persetujuan mungkin tidak peduli pada kebenaran itu. Prinsip ini berlaku bukan hanya untuk memperbaiki software dengan benar, tetapi juga hampir semua hal di tempat kerja

  • Menurut saya satu-satunya cara keluar dari situasi neraka ini adalah bekerja di tempat yang leadership-nya sudah cukup matang untuk memahami hal-hal seperti ini
    Jika Anda harus menjelaskan mengapa kualitas itu penting, mereka setidaknya sama tidak tahunya dengan Anda, mungkin malah lebih. Organisasi seperti itu harus menerima nasibnya. Sebaliknya, di perusahaan yang matang, Anda akan diberi kompensasi lebih cepat dan lebih besar, serta bisa lebih cepat mengembangkan naluri tentang bagaimana bisnis seharusnya berjalan. Tentu saja Anda harus membuktikan sendiri bahwa waktu yang dicurahkan benar-benar berujung pada perbaikan nyata, dan bukan dorongan Don Quixote ala amatir

• Dari kualitas, waktu singkat, kompleksitas komunikasi yang rendah, dan biaya kecil, kira-kira hanya tiga yang bisa didapat, dan di sini waktu lebih mirip variabel dependen
  Orang-orang mencoba menerapkan proses dan struktur ala pabrik pada perangkat lunak, padahal perangkat lunak adalah olahraga tim sekaligus bidang rekayasa. Seperti halnya tim basket tidak diajarkan atau dibangun dengan memecahnya menjadi prosedur dan checklist per tahap serangan, komunikasi harus diminimalkan dan tim harus dibuat bergerak sebagai satu kesatuan. Ini bukan soal membangun proses, melainkan membentuk tim dan individu. Buatlah rencana, tetapi seperti kata Moltke, tidak ada rencana operasi yang tetap pasti setelah kontak pertama dengan musuh. Namun pola pikir bisnis percaya bahwa karena rencana tidak berjalan sesuai perkiraan, maka perlu ditambahkan lebih banyak proses, dan pada kegagalan berikutnya membuat manajer bisa menyalahkan individu. Proses punya tempat untuk memastikan pekerjaan terjadi dalam kerangka hukum dan moral, serta mengurangi kondisi buruk seperti tanpa sengaja mempertaruhkan seluruh dana hedge fund saat pengujian. Namun di sebagian besar startup dan perusahaan, proses dipakai dengan cara yang tidak menempatkan tim sebagai pusat

  • Analogi konstruksi adalah analogi yang buruk. Compiler-lah yang melakukan konstruksi, sedangkan tim pengembang melakukan desain berulang dengan asumsi adanya umpan balik dan penyesuaian yang sering
    Kita tidak berteriak kepada arsitek tradisional menanyakan kapan selesai. Biasanya selesai ketika pelanggan puas atau mengambil keputusan. Banyak pengembangan juga mirip seperti itu

• Saya ragu apakah ada aktivitas manusia yang berhasil mengajarkan atribut yang disebut kualitas
  Berdasarkan pengalaman, kemampuan menghasilkan sesuatu yang berkualitas hanya diperoleh lewat latihan, latihan, dan latihan

  • Bisa dibilang semua praktik industri memang seperti itu
    Sebaliknya, judulnya hanya berarti bahwa pemrograman bukanlah praktik industri. Bagi orang yang memperhatikan, ini semestinya jelas, tetapi sebagian orang menolak melihatnya sampai akhir
  • Pendidikan yang baik sebagian besar adalah menciptakan situasi agar pembelajar bisa berlatih secara efektif
    Lihat saja menulis: banyak orang belajar cara meningkatkan kualitas. Caranya dengan memberi panduan tentang apa yang bisa ditulis, dan yang lebih penting, bagaimana meninjau kembali dan memperbaiki kualitas tulisan yang baru saja dibuat
  • Seni juga termasuk. Semakin dalam pendidikannya, semakin berfokus pada perbedaan kecil dan kualitas
    Latihan selalu membantu, tetapi kualitas juga dipelajari dan diasah oleh banyak orang
  • Karena masalah kesehatan, saya tidak bisa lagi terbang secara profesional, tetapi saya merasa hal-hal seperti ini dipelajari di dunia penerbangan dan kurang ada di industri teknologi
    Saat belajar terbang, kita mempelajari standar, tetapi seiring waktu diajarkan untuk mempersempit toleransi. Misalnya, jika standar ketinggian dalam steep turn adalah ±100 kaki, itu adalah batas minimum; targetnya 50 kaki, 20 kaki, bahkan sampai jarum hampir tidak bergerak. Tujuannya adalah “lebih baik, selalu lebih baik, apa yang bisa dilakukan lebih baik?”, dan dalam penerbangan seseorang lulus jika memenuhi semua aspek, bukan berdasarkan rata-rata keseluruhan. Secara budaya, “memuaskan” bukan akhir, melainkan titik awal
    Saya merasa sikap seperti ini menciptakan model yang jauh lebih kolaboratif. Dalam penerbangan, semua orang benar-benar ingin semua orang berhasil, dan jika seseorang gagal, diri sendiri juga punya sebagian tanggung jawab. Ada budaya bahwa ketika terjadi kesalahan, kita harus mencari cara untuk mengurangi kemungkinan kesalahan ke depannya, dan di maskapai, Flight Operations Quality Assurance (FOQA) juga berperan besar. Di organisasi operasi kecil di daerah terpencil, ini lebih informal, tetapi sebagian besar cukup dekat dengan budaya “tanpa menyalahkan”, dan intinya adalah “bagaimana kita membuatnya lebih baik?”
    Kualitas, pengambilan keputusan, dan “melakukan hal yang benar” adalah inti budaya penerbangan. Pada operator bereputasi, keputusan bahwa cuaca terlalu buruk untuk dilakukan dengan aman langsung berujung pada pembatalan operasi, dan mereka tidak memaksakan berangkat demi menyelesaikan pekerjaan. Industri teknologi yang baru saya masuki terasa seperti kebalikannya. Konsep minimum viable product itu sendiri menunjukkan masalahnya. Seharusnya bukan “minimum viable”, melainkan “produk dengan kualitas minimum yang dapat diterima sebagai titik awal”. Minimum tidak boleh dijadikan target; minimum hanyalah titik awal
  • Latihan hanya bermakna jika tujuannya adalah menciptakan kualitas
    Jika yang dilatih hanya membuat sampah, Anda hanya akan menjadi mahir membuat sampah. Memang ada orang yang tidak peduli pada kualitas, jadi dalam kasus seperti itu, seluruh premisnya runtuh