Bagaimana saya bisa dibayar untuk mengurangi hutang teknis?

Saat ini saya bekerja untuk perusahaan kecil yang memiliki beberapa produk yang rumit secara teknis. Saya satu-satunya pengembang untuk salah satunya. Sekitar setahun yang lalu, saya mendapatkan versi produk warisan dan mulai "mendukung" itu.

Pelanggan hanya berbicara tentang fitur baru, nilai bisnis, dan lainnya dari jenis itu. Masalahnya adalah, meskipun kodenya dalam C #, itu cukup prosedural. Tidak ada abstraksi, kelas hanya digunakan di mana Visual Studio membutuhkannya - Formulir, misalnya. Implementasi kelas-kelas ini sangat buruk dan kodenya sangat sulit untuk dipelihara.

Sepanjang tahun ini saya menghabiskan waktu saya sendiri untuk refactoring. Dalam versi terbaru, ada banyak abstraksi dan semacamnya. Saya harus menerapkan kembali sejumlah komponen dari awal dan saya benar-benar merasa bahwa menambahkan fitur baru atau mengubah perilaku ke komponen-komponen ini JAUH lebih mudah daripada yang lain.

Masalahnya adalah, saya menghabiskan waktu saya sendiri. Saya sangat suka hasilnya, tapi saya tidak suka bekerja 12 jam per hari. Pernahkah Anda ke situasi yang sama? Apa yang harus saya coba? Saya sudah mencoba membahasnya, tetapi masih belum berhasil.

Saya hanya takut pada saat ketika kami memutuskan untuk mengimplementasikan fitur baru yang membutuhkan banyak perubahan pada kode legacy. Itu bisa sangat mengejutkan bagi pelanggan: mengapa Anda perlu 8 jam untuk mengubah ikon ini? Pelanggan tidak peduli bahwa ada 500 tempat dalam kode yang perlu saya ubah. Dan saya juga harus menemukan semua 500 tempat ini terlebih dahulu.

Ada ide?

Langkah 1: Berhenti bekerja lembur tanpa dibayar.

Anda telah melatih pelanggan dan manajer Anda selama setahun untuk meyakini bahwa laju perkembangan saat ini adalah apa yang harus diharapkan. Ini adalah bagian dari alasan mengapa mereka tidak mengerti mengapa hal "sederhana" bisa memakan waktu sehari penuh untuk dilakukan. Anda tidak perlu menyandera mereka dan berusaha melukai proyek. Tetapi Anda perlu menjelaskan bahwa harapan mereka terlalu tinggi dan Anda perlu pengembang lain atau lebih banyak waktu sebelum batas waktu. Buat poin khusus untuk menyebutkan kepada manajer Anda bahwa Anda telah bekerja lembur tanpa dibayar dan berencana untuk tidak melakukan itu sebanyak. Bahkan jika Anda memotongnya menjadi 9 jam hari, perbedaannya akan diperhatikan. Jika manajer Anda bertanya kepada Anda mengapa Anda tidak menyelesaikan pekerjaan Anda, Anda dapat menunjukkan fakta bahwa Anda telah membuat titik untuk memperingatkannya bahwa ini akan menjadi masalahnya.

Langkah 2: Buat catatan

Hanya karena Anda tidak punya waktu untuk melakukan pekerjaan, tidak berarti Anda tidak dapat membuatnya lebih mudah ketika pekerjaan (semoga) selesai. Pantau terus ide-ide yang Anda miliki untuk memperbaiki kode dan bawalah mereka ke rapat agar orang lain mengetahui kekhawatiran Anda. Akhirnya, Anda akan menemukan patch lambat atau orang-orang akan mulai memahami bahwa kekhawatiran Anda memiliki nilai. Ketika waktu ini tiba, Anda sudah memiliki beberapa ide dasar tentang apa yang harus dilakukan daripada membuatnya kering karena Anda belum melihat bagian kode dalam beberapa saat.

... kode ini sangat sulit untuk dipelihara.

Ini cara Anda bersama manajemen. Tunjukkan bahwa biaya "hanya" untuk memperbaiki bug dan menambahkan fungsionalitas baru lebih besar daripada biaya refactoring dan penulisan ulang kode.

Misalnya jika dengan kode saat ini, fitur baru akan membutuhkan 2 minggu untuk ditambahkan dan kemudian sejumlah besar waktu untuk mempertahankan (mis. 1 hari seminggu), tunjukkan bahwa dengan seminggu refactoring Anda dapat menyelesaikan pengembangan dalam 1 1/2 minggu tetapi Anda akan memotong pemeliharaan menjadi 1 hari dalam sebulan (atau kurang). Angka-angka ini akan menunjukkan bahwa apa yang Anda lakukan adalah hemat biaya dalam jangka menengah hingga panjang walaupun ada biaya jangka pendek.

Walaupun perusahaan mungkin tidak suka menghabiskan uang sekarang, mereka akan melihat bahwa manfaat potensial jauh lebih besar - yaitu Anda akan lebih produktif menghasilkan kode lebih banyak dalam waktu lebih sedikit dan kode itu akan kualitas lebih baik.

Terapkan Aturan Kepanduan. Biarkan kode sedikit lebih rapi (mis. Dengan utang teknis lebih sedikit) setiap kali Anda menyentuhnya.

Luangkan waktu untuk melakukan ini dalam semua perkiraan yang Anda berikan. Kemudian, secara ajaib, seiring waktu hutang teknis akan lenyap dan Anda akan dibayar untuk melakukannya.

Pendekatan ini jauh lebih mudah daripada secara eksplisit mencoba mengukir waktu (dan karena itu meyakinkan pelanggan / manajer untuk membayar) untuk hutang teknis. Ini memberi Anda perasaan profesionalisme yang jauh lebih besar dan "pekerjaan yang dilakukan dengan baik". Dan akhirnya, pelanggan dan manajer Anda akan berterima kasih untuk itu dalam jangka panjang, bahkan jika mereka tidak mengerti bagaimana itu terjadi .....

Ini kurang lebih adalah kenyataan menyedihkan dari pemrograman pemeliharaan. Anda terjebak dengan apa yang Anda ditugaskan untuk mempertahankan dan jika orang yang membayar tagihan tidak ingin membayar apa yang dia anggap sebagai perubahan tanpa manfaat, maka perubahan itu cenderung tidak dilakukan.

Jika Anda ingin membuat kasus agar perubahan ini didanai, maka simpan log semua tempat yang harus Anda ubah bahkan untuk pembaruan yang paling sederhana sekalipun. Setelah beberapa perubahan, diskusikan log itu dengan manajer Anda. Jika Anda dapat mendokumentasikannya, ada kemungkinan (walaupun sangat tipis) bahwa orang yang memiliki dompet akan menyadari bahwa sebenarnya lebih murah dalam jangka panjang untuk membersihkan kode sekarang karena akan membuat perubahan di masa depan lebih murah.

Peluang Anda untuk menjual peningkatan ini semakin lama produk ini diharapkan akan digunakan. Peluang juga meningkat jika kegagalan dalam produk kemungkinan menyebabkan masalah hubungan masyarakat bagi pelanggan atau biaya uang pelanggan.

Kecuali itu, pelajari apa yang Anda bisa dan pindah ke posisi lain dengan sedikit perawatan.

Anda perlu menunjukkan kepada manajemen Anda bagaimana cara refactoring dan meningkatkan produk akan menguntungkan perusahaan.

Pelanggan tidak akan peduli apakah kode itu indah atau jelek asalkan kode itu berfungsi, dan manajemen tidak akan bersemangat untuk menjelaskan kepada pelanggan bahwa apa yang telah mereka bayar dirancang dengan buruk dan diimplementasikan dengan buruk. Pada saat yang sama, manajemen tidak akan mau memakan biaya waktu pengembangan yang tidak meningkatkan produk dengan cara yang terlihat (dapat ditagih).

Jadi ... Anda harus meyakinkan manajemen bahwa perubahan yang Anda usulkan akan membantu perusahaan:

• Tunjukkan pada mereka bahwa arsitektur yang lebih baik akan memungkinkan Anda untuk menambahkan fitur baru dengan lebih cepat.
• Jelaskan bahwa dengan melanjutkan sepanjang jalan saat ini mereka akan melukis diri mereka sendiri ke sudut.
• Berikan contoh perubahan yang sangat mahal untuk dilakukan dalam sistem saat ini, tetapi yang sederhana dan murah dengan desain yang lebih baik.
• Melacak waktu yang dihabiskan untuk mempertahankan kode lawas vs menambahkan fitur yang dapat dijual. - Bantu mereka menjelaskan kepada pelanggan yang ada dan yang akan datang bahwa sementara sistem yang ada cukup bagus, arsitektur baru yang dimodernisasi akan memungkinkan banyak peningkatan baru yang hebat, keandalan yang lebih baik, dan sebagainya.
• Mitigasi risiko yang terkait dengan perubahan yang Anda usulkan. Manajer menolak risiko, dan menyapu perubahan pada sistem yang ada tampaknya berisiko.
  • Prioritaskan modernisasi berbagai komponen sesuai dengan biaya dan manfaat, dan pastikan manajemen setuju dengan prioritas Anda.
  • Gunakan pengujian unit untuk membantu memastikan bahwa komponen yang dimodernisasi akan kompatibel dengan kode warisan yang tersisa.
• Lacak kemajuan upaya modernisasi. Tunjukkan keuntungan sesegera mungkin, tapi ingatkan semua pihak bahwa masih banyak yang harus dilakukan.

Anda mungkin tidak menyadarinya, tetapi Johnny Cash memprediksi gerakan refactoring dan menulis lagu tentang cara terbaik untuk refactor basis kode besar yang ada.

Tentu saja, ia harus membungkusnya dengan metafora otomotif sehingga audiensnya bisa mengaitkannya.

"One Piece at a Time" - Johnny Cash

Sepertinya Anda bisa menagih pelanggan untuk waktu perubahan "harus" ambil dan masih keluar WAY di depan dalam jangka panjang.

Jika Anda menikmati membersihkan kode (dan sepertinya Anda melakukan setidaknya sedikit), maka teruskan terus tetapi jangan sampai Anda kelelahan karenanya. Itu tidak baik bagi Anda, perusahaan Anda, atau pelanggan Anda lainnya.

Pastikan bahwa manajemen Anda dan siapa pun yang bekerja dengan pelanggan tahu bahwa kode tersebut tidak dalam kondisi terbaik sehingga mereka dapat membuat keputusan berdasarkan informasi - hanya karena Anda memiliki kode itu tidak berarti Anda harus membuat keputusan bisnis mengenai hal itu, jika mereka tidak mengetahui masalah dengan kode maka mereka tidak dapat melakukan pekerjaan mereka.

Meskipun aplikasi klien memiliki hutang teknis, jangan lupa, mereka mungkin dikenakan sedikit diskon. Mereka mungkin tidak dibuat sadar akan hal ini, tetapi itulah yang terjadi ketika Anda mengambil tawaran terendah.

Mereka perlu memutuskan apakah mereka ingin membayar harga penuh untuk perubahan fitur atau melakukannya tanpa mereka. Itu pilihan mereka. Anda dapat membiarkan mereka membuat keputusan atau terus bekerja secara gratis. Anda dapat mencoba dan menyebutkan pekerjaan pembersihan yang Anda lakukan dan menawarkan sedikit diskon untuk pekerjaan yang diselesaikan. Sekali lagi, itu pilihan mereka.

Cara saya mendekati ini adalah mulai dengan menjelaskan konsep utang teknis kepada bos Anda untuk memastikan mereka mendapatkannya. Pendekatan itu dari garis bawah, perspektif bisnis. Setiap kali mereka meminta fitur baru, utang teknis yang terkandung dalam produk memengaruhi efisiensi Anda, dan karenanya setiap fitur sedikit lebih mahal karena utang ini.

Setelah mereka mengerti apa yang Anda bicarakan, cobalah untuk bernegosiasi untuk sedikit waktu Anda untuk mengurangi hutang teknis. Di perusahaan saya, kami telah cukup berhasil dengan mengajukan petisi untuk 10% dari setiap waktu pengembang untuk mengerjakan pengurangan utang teknis.

Setelah Anda menyisihkan waktu untuk mengerjakan ini, pastikan Anda benar-benar menggunakannya (dan jangan hanya bekerja 10% lembur untuk melakukannya - tetap berpegang pada senjata Anda). Buat katalog barang-barang hutang teknis dan prioritaskan dan mulailah mengukir. Anda harus makan gajah satu gigitan sekaligus.

Dan jangan lupa untuk mempertimbangkan alat yang lebih baik. Resharper adalah alat refactoring yang bagus yang dihubungkan ke Visual Studio.