Ketika Penambahan Fitur Mulai Memakan Waktu Lebih Lama

Sistem yang baru dibangun biasanya terasa cepat di awal. Fitur pertama selesai dalam hitungan hari, permintaan kedua dan ketiga sama lancarnya. Lalu suatu saat polanya berubah: permintaan yang terdengar sederhana ternyata menyentuh banyak bagian, perubahan kecil mengharuskan pengujian ulang area yang seharusnya tidak terkait, dan tim mulai ragu-ragu sebelum menyebut estimasi.

Pada tahap ini penyebabnya jarang berupa satu bug atau satu orang. Penyebabnya biasanya akumulasi keputusan kecil yang masuk akal pada waktunya masing-masing: modul yang memakai tabel milik modul lain karena lebih cepat saat itu, aturan bisnis yang tertulis di tiga tempat karena tidak ada yang tahu tempat resminya, ketergantungan antar bagian yang tumbuh tanpa pernah digambar.

Akibatnya lebih dulu terlihat pada kecepatan daripada pada kesalahan. Sistem tetap berjalan, tidak ada yang rusak, tetapi setiap langkah baru terasa lebih berat dari sebelumnya.

Arsitektur dinilai dari biaya perubahan

Cara kami melihat kondisi semacam ini adalah dengan mengukur biaya perubahan: seberapa banyak bagian yang harus disentuh untuk satu permintaan yang wajar. Dari sana terlihat apakah perlambatan datang dari satu area yang memang padat, atau dari struktur yang membuat semua area saling menahan.

Tanda yang biasanya kami temukan bersamaan:

• Perubahan kecil mengharuskan pengujian di area yang terdengar tidak terkait.
• Aturan bisnis yang sama tertulis di beberapa tempat dan isinya mulai berbeda.
• Hanya satu atau dua orang yang berani mengubah bagian tertentu.
• Estimasi selalu ditambah buffer yang sulit dijelaskan.

Perbaikannya tidak selalu berupa pembangunan ulang. Yang paling sering masuk akal adalah mengurai ketergantungan sedikit demi sedikit pada area yang paling sering berubah, sehingga biaya perubahan turun tanpa menghentikan pengiriman fitur. Membangun ulang dari awal kami pertimbangkan hanya ketika biaya mengurai sudah melebihi biaya memulai lagi, dan keputusan semacam itu layak diambil dengan angka di tangan.

Kalau tim Anda sedang merasakan perlambatan semacam ini, penilaian arsitektur biasanya memberi jawaban yang cukup jelas: bagian mana yang menahan, dan urutan perbaikan seperti apa yang masuk akal untuk setahun ke depan.