Tidak ada yang tahu seberapa besar produk perangkat lunak bekerja – Beragampengetahuan

Perusahaan teknologi besar dan berkembang pesat sering kali beroperasi dalam “kabut perang” pada sistem mereka sendiri. Pertanyaan sederhana seperti “Bisa ketik fitur akses pengguna Y kadang ada nol Orang-orang dalam organisasi dapat menjawab pertanyaan-pertanyaan ini, dan seseorang seperti peneliti harus menggali lebih dalam untuk mengetahuinya.

Bagaimana ini bisa terjadi? Bukankah para insinyur yang membuat perangkat lunak tersebut seharusnya mengetahui fungsinya? Bukankah jawaban-jawaban ini dicatat secara internal? Lebih baik lagi, bukankah pertanyaan-pertanyaan ini mudah dijawab dengan melihat dokumentasi pengguna akhir yang dapat dilihat publik? Perusahaan teknologi penuh dengan orang-orang bergaji tinggi yang tahu apa yang mereka lakukan^{. Mengapa orang-orang tersebut tidak mengetahui fungsi produk mereka?}

Perangkat lunak itu sulit

Produk perangkat lunak berukuran besar terlalu rumit. Saya banyak menulis tentang ini di sifat-sifat jahattetapi versi singkatnya adalah Anda dapat menangkapnya banyak Tambahkan nilai dengan menambahkan fungsionalitas canggih. Contoh umum adalah fitur yang membuat produk inti tersedia bagi lebih banyak pengguna. Misalnya, kemampuan untuk menghosting sendiri perangkat lunak tersebut, atau mencobanya secara gratis, atau menggunakannya sebagai organisasi besar dengan kontrol kebijakan terpusat, atau melokalkannya dalam berbagai bahasa, atau menggunakannya di negara-negara dengan undang-undang yang ketat mengenai cara kerja perangkat lunak tersebut, atau menggunakannya oleh pelanggan dengan regulasi ketat seperti pemerintah, dll. Fitur-fitur ini (mudah-mudahan) transparan bagi sebagian besar pengguna, Namun mereka tidak bisa bersikap transparan kepada perusahaan teknologi itu sendiri.

Mengapa fitur-fitur ini rumit? Karena Mereka memengaruhi semua fitur lain yang Anda buat. Jika Anda menambahkan kontrol organisasi dan kebijakan, Anda harus membuat kontrol kebijakan untuk setiap fitur baru yang Anda tambahkan. Jika Anda melokalkan produk Anda, Anda harus menyertakan terjemahan untuk setiap fitur baru. dll. Pada akhirnya, Anda mencoba menentukan apakah pelanggan perusahaan yang dihosting sendiri di UE memiliki akses ke fitur tertentu, dan tidak ada yang tahu – Anda harus membaca kode atau melakukan beberapa eksperimen untuk mengetahuinya.

Tidak bisakah Anda tidak membangun fitur-fitur ini sejak awal? Tentu, tapi itu akan meninggalkan a banyak uang di atas meja^{. Faktanya, mungkin perbedaan terbesar antara teknologi kecil dan teknologi besar adalah bahwa teknologi besar didirikan untuk mendapatkan nilai lebih dengan memanfaatkan semua fitur yang membosankan dan canggung ini.}

dokumen

Mengapa kami tidak bisa mencatat interaksi satu kali saja untuk setiap fitur baru yang kami buat? Saya pikir hal ini mungkin secara teori dan memerlukan banyak usaha serta dukungan dari atas ke bawah, namun sangat sulit dalam praktiknya.

Masalah intinya adalah Sistem berubah dengan cepat ketika Anda mencoba mencatatnya. Dengan waktu yang cukup, bahkan satu orang pun dapat mendokumentasikan sistem statis yang kompleks karena mereka dapat menyelesaikannya secara perlahan. Namun begitu sistem mulai berubah, orang-orang yang mencoba mendokumentasikannya kini harus bergerak lebih cepat daripada yang bisa diubah oleh sistem. Hampir mustahil untuk merekamnya tanpa banyak tenaga.

Lebih buruk lagi, belum tentu ada niat sadar (atau niat apa pun) di balik sebagian besar perilaku sistem. Mereka muncul begitu saja dari cara sistem diatur, sebagai interaksi dari serangkaian pilihan “default”. Jadi orang yang mengerjakan dokumentasi tidak hanya menuliskan pilihan yang dibuat oleh insinyur, Mereka untuk pertama kalinya menemukan cara kerja sistem.

Jadi siapa yang tahu jawabannya?

Satu-satunya cara yang dapat diandalkan untuk menjawab pertanyaan-pertanyaan ini adalah dengan melihat basis kode. Saya pikir ini sebenarnya adalah alasan struktural mengapa para insinyur memiliki kekuatan institusional di perusahaan-perusahaan teknologi besar. Tentu saja, para insinyur juga demikian Menulis perangkat lunak, namun yang lebih penting mereka bisa Jawab pertanyaan tentang perangkat lunak.

Sebenarnya, Kemampuan menjawab pertanyaan perangkat lunak adalah salah satu fungsi inti tim teknik. Pemahaman terbaik tentang perangkat lunak sering kali ada di benak para insinyur yang menggunakannya setiap hari. Jika basis kode dimiliki oleh tim teknik yang sehat, biasanya Anda tidak memerlukan siapa pun untuk menyelidikinya – Anda cukup bertanya kepada seluruh tim dan setidaknya satu teknisi akan segera mengetahui jawabannya karena mereka sudah memahami bagian kode tersebut.

Ketika perusahaan teknologi merestrukturisasi tim mereka, mereka sering kali menghancurkan pengetahuan diam-diam ini. Jika tidak ada tim yang memiliki pengalaman dengan suatu perangkat lunak, maka masalahnya harus diselesaikan dengan cara penyelidikan: Beberapa insinyur harus mencari tahu. Biasanya hal ini terjadi melalui beberapa kombinasi interaksi dengan produk (mungkin dalam lingkungan pengembangan di mana Anda dapat dengan mudah mengatur skenario tertentu), membaca basis kode, atau bahkan melakukan “operasi eksplorasi” untuk melihat apa yang terjadi ketika Anda mengubah potongan kode atau memaksa pemeriksaan tertentu agar selalu menghasilkan nilai true. Ini adalah keterampilan teknis yang berbeda dengan menulis kode (walaupun kedua keterampilan tersebut saling terkait, tentu saja.)

Menulis perangkat lunak lebih mudah daripada menafsirkannya

Berdasarkan pengalaman saya, sebagian besar insinyur dapat menulis perangkat lunak, namun hanya sedikit yang dapat menjawab pertanyaan tentang perangkat lunak dengan andal. Saya tidak tahu mengapa ini terjadi. Tidakkah Anda perlu menjawab pertanyaan tentang perangkat lunak untuk menulis perangkat lunak baru? Meskipun demikian, itu benar. Teori terbaik saya adalah Ini masalah iman. Banyak insinyur lebih memilih terjebak dengan masalah mereka kode (setidaknya berfungsi di mesin mereka) daripada mesin mereka Menjawab (Ini mungkin sepenuhnya salah).

Saya menulis tentang ini di Bagaimana saya memberikan kejelasan teknis kepada pemimpin non-teknis. Kesulitan inti terletak pada Anda selalu putus asa. Anda harus merasa nyaman dengan kemungkinan bahwa Anda salah, yang merupakan pola pikir yang berbeda dari menulis kode (di mana Anda biasanya dapat membuktikan bahwa pekerjaan Anda benar). Anda juga dapat menulis kode Anda sedetail mungkin saat menulis kode Anda (dan tentu saja saat menulis tes Anda), namun saat Anda menjawab pertanyaan, Anda harus meringkas semuanya menjadi ringkasan. Beberapa insinyur perangkat lunak kebencian Abaikan detailnya.

menyamaratakan

Orang non-teknis (setidaknya mereka yang tidak memiliki pengalaman luas dalam menggunakan produk perangkat lunak) sering berasumsi bahwa para insinyur yang membangun sistem perangkat lunak memahaminya dengan baik. Idenya di sini adalah bahwa sistem harus dapat dimengerti karena dibangun baris demi baris dari (sebagian besar) komponen deterministik.

Namun, meskipun hal ini mungkin berlaku untuk perangkat lunak kecil, Hal ini jarang berlaku untuk sistem perangkat lunak besar. Sistem perangkat lunak yang besar kurang dipahami, bahkan oleh mereka yang paling mampu memahaminya. Bahkan pertanyaan yang sangat mendasar tentang perangkat lunak apa yang biasanya dibutuhkan Riset untuk menjawab. Setelah Anda memiliki jawaban yang pasti, jawaban tersebut mungkin tidak akan bertahan lama – setiap perubahan pada basis kode dapat menimbulkan nuansa dan anomali, sehingga Anda sering kali harus mengerjakan masalah yang sama berkali-kali.

Karena semua ini, Kemampuan untuk menjawab pertanyaan secara akurat tentang sistem perangkat lunak besar sangatlah berharga.