Don’t Touch My Code!!! | Part 1
Analisis Relasi antara Ownership dan Kualitas Software
Kita semua setuju bahwa kualitas dari software akan berbanding lurus atau setidaknya berhubungan langsung dengan kualitas team yang terlibat dalam semua proses pembuatannya. Faktor team yang terlibat sangat besar terhadap kualitas software yang dihasilkan.
Studi dan kajian terhadap kepemilikan dan selanjutnya akan saya sebut sebagai ownership serta pengaruhnya terhadap kualitas software sampai saat ini sangat sedikit sekali. Bahkan sepertinya, belum ada yang membahasnya secara langsung dan terbuka. Walaupun demikian, saya melihat upaya untuk mengetahuinya sudah dilakukan oleh para praktisi software khususnya para manager yang ada pada perusahaan-perusahaan besar. Salah satunya apa yang saya tulis adalah dari hasil kajian mereka dan analisis saya serta teman-teman lainnya yang memegang posisi sebagai leader dari team developer.
Saya melihat suatu pola yang sama di setiap perusahaan terhadap kualitas software yang dibuat. Tidak peduli perusahaan tersebut vendor ataupun end user yang membuat dan mengembangkan sendiri softwarenya. Pola ini terlihat dengan jelas sehingga bisa dilihat terdapat benang merah antara tingkat ownership dan kualitas software yang dihasilkan.
Saya mencoba melakukan penelitian sederhana dengan data yang ada di lapangan dan penelitian literatur dengan mencari beberapa sumber bacaan dengan tema terkait relasi antara ownership dan kualitas software. Berikut adalah hasilnya.
Asumsi Ownership
Ownership terhadap suatu software secara umum adalah istilah yang menggambarkan tingkat kepedulian, kepemilikan, dan tanggung jawab suatu individu atau team terhadap satu bagian atau seluruhnya dari sebuah software. Akan tetapi, pada pembahasan di sini ownership akan lebih ditekankan pada banyaknya kontribusi seseorang dalam software yang dibuat. Semakin banyak source code yang di buat maka bisa disebutkan samakin tingggi ownershipnya dia terhapdap software yang dibuat. Kita dapat menyebutkan ownership Si A 100 % jika seluruh code dibuat oleh nya.
Selanjutnya, berdasarkan hasil diskusi dengan beberapa rekan Project Manager, Product Manager, dan Engineering Manager, ditemukan bahwa ada hubungan yang kuat antara ketidakjelasan dari requirement dan proses software development yang dikerjakan oleh banyak software developer terhadap kualitas software. Semakin tidak jelas requirement dan semakin banyak orang terlibat maka akan semakin meningkat pula tingkat un konsistensi, gangguan komunikasi, dan tidak selarasnya tujuan. Semua itu, pada akhirnya mengarah pada menurunnya kualitas software.
Fakta yang menarik, tidak seperti aspek yang terkait langsung dengan software contohnya kompleksitas library dari dependency dan ukuran source code, tertanya level ownership bisa dikondisikan. Ownership bisa diubah dengan mengatur prosess dan kebijakan. Kita dapat mengatur ownership berdasarkan dari kondisi dari dampak ownership terhadap kualitas software. Manager dan Team Lead dapat mengatur keputusan berdasarkan kondisi di atas.
Apabila dampak ownership terhadap kualitas software tidak terlalu memberikan effect yang besar maka tidak perlu membuat pembagian kerja terlalu ketat. Seperti setiap satu developer harus bertanggung jawab secara tepat unutk satu service atau satu komponen. Kita dapat melakukan pembagian tanggung jawab yang lebih tersebar. Seperti, satu orang dapat menghandle lebih dari satu service. Akan tetapi, jika masalah ownership ini sangat tinggi dampaknya terhadap kualitas dari software maka manajer harus benar-benar membuat scope ownership lebih ketat dan lebih kecil jangkauannya. Bahkan kalau diperlukan manajer dapat memonitor dan mereview langsung source code yang dibuat oleh beberapa developer dengan level kompetensi yang masih rendah.
Teori Seputar Ownership
Terdapat beberapa studi yang telah dilakukan terkait ownership pada software development dan berikut adalah beberapa ulasan dari teori-teori yang ada.
F. Rahmah dan P. Devanbu dalam artikelnya yang berjudul “Ownership and Depect : a fine grade study of Authorship”. ICSE, 2011, menyatakan:
“Pengalaman dan ownership dari team developer sangat berdampak terhadap kualitas software yang dihasilkan”.
Penelitian dilakukan dengan cara terperinci terhadap fragment code yang mengarah pada perbaikan dari kualitas software. Pada artikel diatas dijelaskan bahwa kebijakan ownership berbeda secara signifikan pada software yang bersifat open source dan komersial.
E. J. Weyuker, T. J. Ostrand, dan R. M. Bell dalam artikelnya berjudul “Do too many cooks spoil the broth? using the number of developers to enhance defect prediction models”. Empirical Softw. Engg., 13(5):539–559, 2008.
Mereka menyatakan bahwa selain efek ownership terdapat juga pengaruh dari jumlah banyaknya individu yang terlibat dalam satu team. Akan tetapi, data yang disampaikan adalah data prediksi dan tidak menyertakan data proporsi individu pada software yang di buat. Dengan demikian, hasil ini dirasa kurang menarik karena datanya bukan dari kejadian nyata yang diolah secara statistik.
Senada dengan penjelasan di atas, A. Meneely dan L. A. Williams dalam artikelnya yang berjudul “Secure open source collaboration: an empirical study of linus’ law”. In Proceedings of the ACM Conference on Computer and Communications Security, 2009 memberikan penjelasan sebagai berikut.
Mereka melakukan penelitian terhadap jumlah developer yang mengerjakan bagian dari linux kernel khususnya security vulnerability. Mereka mendapatkan temuan bahwa jika jumlah developer lebih dari sembilan developer yang berkontribusi pada satu file source code maka 16 kali tinggi munculnya vulnerability pada linux kernel tersebut.
Metode baru yang lagi banyak digunakan pada proses pembuatan software seperti Extreme Programming (XP) memang menunjukan kolaborasi dan kolektif ownership yang lebih baik, tetapi kurang data empiris dari kejadian nyata khususnya pada software yang berukuran besar atau enterprise.
Saya sendiri melihat bahwa pengetahuan terhadap domain bisnis, software aplikasi, bahkan specific component yang pernah dibuat akan memberikan dampak yang besar terhadap kualitas software. Developer yang pernah membuat jenis domain atau komponen yang sama akan memberikan bantuan terhadap proses memaintenance kualitas software yang lebih baik.
Hal yang dijelaskan di atas, senada dengan yang dijelaskan oleh W. Boh, S. Slaughter, dan J. Espinosa. Learning from experience in software development: A multilevel analysis. Management Science, 53(8):1315–1331, 2007. Team yang memiliki expertise pada suatu project yang sama akan memberikan dampak yang lebih tinggi dan lebih baik daripada team dengan pengalaman yang tidak ada relevansi. Walau secarang level skillnya mungkin mereka adalah senior bahkan expert akan tetapi kalau tidak ada pengalaman pada domain business yang akan dibuat maka hal ini akan kurang memberikan dampak. Lebih baik memiliki sedikit expert yang relevansi tinggi daripada memiliki banyak expert tetapi tidak ada relevansinya.
Studi kualitatif yang dilakukan pada 17 software komersial oleh, B. Curtis, H. Krasner, dan N. Iscoe. A field study of the software design process for large systems. Communication of the ACM, 31(11):1268–1287, 1988. Menjelaskan bahwa pengetahuan yang dangkal dari software developer terhadap business domain yang lagi dikerjakan merupakan peringkat ketiga sebagai silent killer dari kualitas software.
Pada artikel sebelumnya dijelaskan pula software developer yang luar biasa adalah mereka para jagoan coding yang selain memiliki skill tinggi tetapi memiliki pengetahuan yang dalam terhadap bisnis model atau domain bisnis yang dikerjakan. Dengan demikian, biasanya mereka dapat membuat dan mendesain sistem yang memberikan prilaku software yang diharapkan oleh customer.
Selanjutnya pertanyaan muncul, bagaimana kita dapat mengetahui siapa yang memiliki pengetahuan domain yang bagus? Untungnya kita dapat mengetahui nya dari kemampuan dia menjelaskan potongan code yang ada pada suatu software dengan bisnis model tertentu. Semakin dalam dan detail dia dapat menjelaskan maka yakinlah dia memiliki ownership yang tinggi pada software yang dibuat. Kita bisa menyebutkan bahwa orang ini sangat rekomendasi untuk berada dalam team kita.
A. Mockus dan D. Weiss dalam jurnalnya yang berjudul Predicting risk of software changes. Bell Labs Technical Journal, 5(2):169–180, 2000 menyatakan bahwa perubahan pada source code yang dilakukan oleh developer yang memiliki pengalaman lebih banyak pada potongan kode tersebut maka akan bisa diprediksi bahwa apa yang dikerjakannya akan sangat kecil sekali memberikan kesalahan atau bug. Sebaliknya perubahan yang dilakukan oleh yang yang baru sekali memegang suatu potongan source code akan memiliki kemungkinan besar ada bug yang menyertainya.
Mungkin penjelasan mengenai teori seputar ownership sudah cukup banyak dan mewakili selanjutnya kita bahas mengenai Metrik dan Terminologi yang akan kita gunakan dalam penelitian selanjutnya. Adapun penjelasannya akan kita lanjutkan di Artikel Don’t Touch My Code!!! | Part 2.
References
- https://www.microsoft.com/en-us/research/publication/dont-touch-my-code-examining-the-effects-of-ownership-on-software-quality/
- Quality Code: Software Testing Principles, Practices, and Patterns 3rd Edition
