Anda tidak akan pernah membaca kode sumber milik Anda sendiri. Itu wajar. Tapi kualitas kode bagi pemilik bisnis bukan sekadar gengsi teknis, ini risiko bisnis yang akan muncul di laporan keuangan Anda kemudian, biasanya di saat yang paling buruk. Tagihannya datang tepat pada hari Anda mencoba berganti vendor dan baru sadar Anda tidak bisa.
Selama lima belas tahun, saya sudah mewarisi banyak sekali sistem buatan orang lain. Sebagian menyenangkan untuk dikembangkan. Sebagian lain adalah ladang ranjau, di mana menyentuh satu layar bisa merusak tiga hal lain yang tak terduga. Pemiliknya, di kedua kasus itu, membayar biaya pembuatan yang kurang lebih sama. Yang membedakan adalah apa yang terjadi setelahnya, dan itu semua bergantung pada kualitas yang tidak bisa mereka lihat saat itu.
Jadi pertanyaan sebenarnya adalah, bagaimana Anda menilai sesuatu yang tidak bisa Anda baca? Anda menilainya lewat sinyal proxy. Anda tidak perlu paham kode untuk melihat apakah orang yang menulisnya bekerja seperti profesional, atau seperti orang yang mengambil jalan pintas.
Kualitas itu tak terlihat, sampai Anda membayar mahal untuknya
Ini kebenaran yang tidak enak didengar. Sistem yang dibangun murahan dan sistem yang dibangun dengan baik seringkali terlihat identik di hari peluncuran. Layar yang sama, fitur yang sama, demo yang sama. Perbedaannya terkubur dalam cara sistem itu disusun, dan baru muncul ke permukaan dalam tiga kondisi ini:
- Saat Anda ingin menambah fitur, dan penawaran harga yang kembali ternyata mengejutkan tingginya "karena rumit."
- Saat perubahan kecil merusak sesuatu yang tidak berhubungan, berulang kali.
- Saat Anda ingin merekrut developer baru atau berganti vendor, dan setiap orang yang melihat kodenya diam-diam mundur.
Ini jebakan yang sama seperti yang saya jelaskan dalam website murah yang berubah jadi kesalahan paling mahal. Kualitas rendah bukan berarti lebih murah. Biayanya hanya ditunda, dan terus berbunga.
Sinyal proxy yang benar-benar bisa Anda cek
Anda tidak bisa membaca kodenya, tapi Anda bisa bertanya dan memperhatikan bagaimana pertanyaan itu dijawab. Sinyal-sinyal ini berkorelasi kuat dengan apa yang sesungguhnya ada di baliknya.
Apakah mereka menulis automated test? Tanyakan langsung, "Apakah kalian menulis test, dan bisa tunjukkan ke saya bahwa test itu berjalan?" Tim yang punya test bisa mengubah sesuatu dengan percaya diri. Tim yang tidak punya, mengklik-klik layar secara manual sambil berharap-harap cemas. Test adalah sinyal terkuat dari tim yang memang berniat agar software-nya bertahan lama, bahkan setelah mereka tidak lagi menanganinya.
Bisakah developer baru langsung produktif dalam hitungan hari, bukan minggu? Tanyakan, "Kalau saya merekrut developer baru besok, berapa lama sampai dia bisa melakukan perubahan dengan aman?" Jawaban yang sehat adalah beberapa hari, dengan panduan setup tertulis. Jawaban yang buruk adalah jawaban yang samar-samar, atau "yah, hanya developer aslinya yang benar-benar paham sistem ini." Jawaban kedua itu adalah situasi sandera.
Apakah ada dokumentasi? Bukan manual seratus halaman. Cukup README yang menjelaskan cara menjalankan proyeknya, di mana letak berbagai bagiannya, dan bagaimana proses deployment berjalan. Keberadaannya menunjukkan bahwa tim itu memikirkan orang yang akan datang setelah mereka, yang mungkin saja adalah Anda sendiri, atau karyawan berikutnya yang Anda rekrut.
Seberapa menakutkan sebuah perubahan? Perhatikan bahasa tubuh vendor saat Anda meminta perubahan kecil. Tenang dan cepat berarti sistemnya tertata rapi. Gugup, mahal, dan lambat berarti setiap perubahan adalah judi. Rasa takut adalah metrik kualitas yang bisa Anda baca dari raut wajah seseorang.
Uji vendor kedua
Ini yang paling penting, dan saya ingin Anda benar-benar meresapinya: bisakah tim lain yang kompeten mengambil alih sistem Anda tanpa harus membangunnya ulang dari nol?
Ini adalah metrik kualitas paling utama karena mencakup semuanya sekaligus. Struktur yang bersih, test, dokumentasi, dependency yang masuk akal. Kalau vendor kedua bisa membaca sistem Anda, memahaminya, dan mengembangkannya dengan aman, berarti kualitas Anda memang benar-benar baik, dan Anda bebas. Anda punya daya tawar. Anda bisa bernegosiasi, berganti vendor, atau membawa pekerjaan ini masuk ke internal perusahaan.
Kalau hanya orang-orang yang membangunnya yang bisa menyentuh sistem Anda, Anda tidak memiliki software itu. Anda menyewanya, dengan harga yang mereka tentukan sendiri, selamanya. Saya pernah melihat pemilik bisnis membayar dua kali lipat harga wajar selama bertahun-tahun, karena pergi darinya secara teknis sudah mustahil.
Anda bisa menguji ini dengan murah sebelum Anda terjebak. Minta developer independen kedua untuk menghabiskan satu atau dua hari berbayar meninjau codebase Anda dan melaporkan hasilnya. Jawaban mereka atas pertanyaan "bisakah kamu mengambil alih ini?" jauh lebih berharga daripada presentasi penjualan mana pun.
Apa yang Anda dapat dari kualitas yang baik
Supaya lebih konkret, ini yang sebenarnya dibayar oleh hal yang tak terlihat itu:
| Kualitas buruk | Kualitas baik |
|---|---|
| Setiap perubahan berisiko memunculkan bug baru | Perubahan aman dan bisa diprediksi |
| Satu orang memegang seluruh pengetahuan sistem | Developer kompeten mana pun bisa masuk dan melanjutkan |
| Terkunci pada satu vendor, tanpa daya tawar | Bebas untuk berganti vendor atau merekrut |
| Biaya terus naik seiring bertambah tuanya sistem | Biaya tetap stabil atau bahkan turun |
| Rasa takut menyelimuti setiap rilis | Percaya diri untuk bergerak cepat |
Tidak ada satu pun dari ini yang terlihat dalam demo. Semuanya baru terlihat delapan belas bulan kemudian. Inilah tepatnya alasan mengapa software harus dievaluasi sebagai bagian dari strategi teknologi yang nyata, bukan pembelian satu kali. Harga beli hanyalah bagian terkecil dari total biaya sesungguhnya.
Yang bisa Anda lakukan
Anda tidak perlu menjadi orang teknis untuk melindungi diri Anda sendiri. Anda hanya perlu bertanya lebih baik dan memperhatikan jawabannya. Untuk proyek berikutnya atau vendor Anda saat ini, tanyakan tiga hal ini: Apakah kalian menulis test? Bisakah developer baru onboarding dalam seminggu? Bisakah tim lain mengambil alih ini kalau saya memintanya? Kualitas dari jawaban-jawaban itu, dan keyakinan di baliknya, memberi tahu Anda hampir segalanya.
Kualitas kode bagi pemilik bisnis pada akhirnya adalah soal keleluasaan pilihan. Kode yang baik menjaga pilihan Anda tetap terbuka. Kode yang buruk merenggutnya satu per satu sampai tidak tersisa apa pun. Kalau Anda ingin penilaian yang jujur dan independen atas sistem yang sudah Anda miliki atau akan Anda beli, tinjauan opini kedua semacam itu adalah salah satu hal paling berguna yang saya lakukan sebagai technical partner. Biayanya hanya sebagian kecil dari risiko terjebak selamanya, dan bisa menyelamatkan Anda bertahun-tahun ke depan.