Pernahkah Anda mendengar tentang tim pengembangan perangkat lunak yang tidak harus menghadapi hutang teknis?

Aku juga. Selain itu:

Para insinyur menghabiskan sekitar sepertiga waktu mereka untuk utang teknis, yang mengurangi moral tim dan biaya perusahaan sekitar 85 miliar dolar per tahun.

Jalur Belajar

Pikirkan saja itu. Ini adalah 85 miliar dolar.

Sepertiga dari semua waktu yang dihabiskan pengembang untuk utang teknis. Ini mengisi pengembang dengan horor. Ini, pada kenyataannya, adalah bagian terburuk dari pekerjaan mereka - dan fakta bahwa bagian bisnis yang lain sering tidak berempati dengan mereka menambah bahan bakar ke dalam api. Tidak ada yang bisa disalahkan, tetapi utang teknis secara universal diremehkan. Karena itu, perusahaan perangkat lunak perlahan-lahan menjadi kaku, sampai mereka kehilangan kemampuan untuk tumbuh, yang tidak memerlukan berbulan-bulan dan bertahun-tahun untuk menulis ulang aplikasi mereka dari awal ... dan waktu seperti itu di pasaran saat ini adalah selamanya.

Utang teknis adalah fenomena biasa, bukan? Kami mulai menulis kode, utang teknis menumpuk, dan boom , tiba-tiba menjadi terlalu banyak. Basis kode kami terperosok di dalamnya, dan kami mengalami kebangkrutan teknis. Karena itu, kami berkelahi dengannya. Kami tahan dengan kebutuhan menyakitkan dan membayar sebagian dari hutang. Terkadang kita berhasil melakukannya, kadang tidak. Ini adalah inti dari pengembangan perangkat lunak. Jadi kami mengatur semuanya.

Tetapi haruskah demikian? Apakah ada hukum dasar pengembangan perangkat lunak yang bertanggung jawab untuk ini? Dan, jika demikian, dapatkah kita menggunakan undang-undang ini untuk keuntungan kita sendiri? Utang teknis adalah hal biasa, tetapi tidak boleh kebangkrutan teknis.

Mari kita beralih ke berbagai bidang sains untuk beberapa kiat, karena hukum termodinamika dapat memberi kita ide-ide kunci untuk memahami mengapa utang teknis tidak terhindarkan.

Macrotrends membuat utang teknis tak terhindarkan

Hukum termodinamika pertama

Juga dikenal sebagai hukum kekekalan energi ; klaim untuk:

Energi total dari sistem tertutup tetap konstan; Mereka mengatakan bahwa itu terus berlanjut seiring waktu.

Dengan kata lain, energi tidak dapat dibuat atau dihancurkan, namun, ia dapat berpindah dari satu bentuk ke bentuk lainnya.

Jika tanpa kesulitan yang tidak perlu, mari kita pikirkan basis kode kita sebagai sistem tertutup . Kami membuang dependensi eksternal dan segala sesuatu yang hidup di luar basis kode kami. Dalam kondisi ini, ada sejumlah pengembang yang tidak berubah, pengembangan fitur dengan kecepatan tinggi secara konsisten - jumlah entropi ( ukuran gangguan dan keacakan dalam sistem ) dalam basis kode kami tetap konstan.

Pengembang kami tidak dapat menjadi supermen dalam satu malam, jadi kami tidak dapat meningkatkan efektivitasnya jika mereka sudah memberikan yang terbaik. Tetapi kami dapat mempekerjakan lebih banyak pengembang, dan ini meningkatkan energi di sistem kami. Itulah sebabnya hukum Brooks benar: "Jika sebuah proyek tidak memenuhi tenggat waktu, maka menambah lebih banyak tenaga kerja akan menunda lebih banyak lagi" - karena itu meningkatkan energi, atau kekacauan, dalam sistem di mana kekacauan sudah hebat.

Perusahaan perangkat lunak yang tumbuh cepat berjuang dengan kekuatan ini sepanjang waktu. Mereka meningkatkan investasi, menggandakan ukuran tim pengembangan secepat pasar tenaga kerja memungkinkan mereka, dan kemudian mereka harus berurusan dengan lompatan besar dalam "energi" dalam basis kode mereka. Hal ini seringkali melebihi kemampuan perusahaan dan dapat menyebabkan peningkatan tajam dalam hutang teknis jika langkah-langkah penanggulangan yang mendesak tidak diambil.

Tapi tunggu sebentar. Mengapa ini menyebabkan peningkatan hutang teknis?

Hukum kedua termodinamika

Kekacauan dalam sistem tertutup tidak dapat berkurang; itu hanya bisa tetap tidak berubah atau meningkat.

Bahkan, sistem tertutup masuk ke keadaan gangguan yang lebih besar secara alami. "Gangguan" ini - yang kita sebut di atas "energi" atau "kekacauan" - disebut entropi. Ivar Jacobson dan rekan-rekannya menyelidiki fenomena entropi dalam basis kode dan memperkenalkan istilah entropi perangkat lunak . Saat Anda membuat perubahan pada basis kode, entropinya meningkat. Kekacauan yang melebar ini adalah penyebab utang teknis.

Kembali ke perusahaan perangkat lunak kami yang berkembang pesat, yang basis pelanggannya terus berkembang dan pasar semakin berkembang. Tim pengembangan mereka yang terus berkembang menggelar fitur siang dan malam untuk mengimbangi pertumbuhan. Jika Anda tidak melakukan apa pun, basis kode hanya akan menjadi lebih membingungkan. Tekanan meningkat.

Saya melihat utang teknis sebagai entropi dalam basis kode. Saya tidak berpikir bahwa dia akan pernah menghilang, pertarungan dengannya akan konstan.

Ron Pragides , wakil presiden teknik di Carta

Saat merencanakan setiap sprint, perusahaan kami menghadapi pilihan: apakah ada sesuatu yang perlu Anda lakukan untuk mengekang kompleksitas yang semakin meningkat atau apakah pantas untuk mengembangkan dan menghadirkan fitur baru?

Hukum termodinamika ketiga dan terakhir menjelaskan mengapa dilema ini bahkan tidak berhubungan erat dengan keadaan sebenarnya.

Hukum Ketiga Termodinamika

Entropi sistem mencapai nilai konstan ketika suhu nol mutlak.

Kedengarannya rumit, tetapi pada kenyataannya, esensinya cukup sederhana, dan meskipun hukum-hukum termodinamika memiliki konsekuensi yang luas (dan kadang-kadang hanya berlebihan), fundamental mereka mudah dipahami. Misalnya, ketika air berbentuk uap, molekul-molekulnya "bebas" bergerak dengan cara yang benar-benar kacau. Entropi ada di mana-mana. Namun, ketika air membeku, molekul-molekulnya "terkunci" dan tetap di tempatnya (kurang lebih). Entropi menurun dan mencapai nilai konstan.

Jadi apa yang bisa kita lakukan untuk mengendalikan entropi perangkat lunak?

Yah, kita bisa berhenti mengembangkan kode baru. Untuk alasan ini, beberapa tim suka "membekukan" kode untuk menguji sistem mereka secara menyeluruh sebelum dirilis ke pelanggan. Jika basis kode tidak lagi berubah, maka entropi tidak meningkat, kekacauan juga, tidak ada konsekuensi yang lebih tak terduga, dan utang teknis tidak meningkat.

Namun, tidak mungkin untuk menjaga kode tetap beku selamanya - kita perlu fitur baru. Jadi satu-satunya pilihan yang tersisa bagi kita adalah refactor.

Proses refactoring kode dapat membantu dalam menghapus entropi perangkat lunak.
Wikipedia

Ekstensi gratis untuk VSCode untuk membantu Anda dengan ini . Mulailah sekarang sebelum semua hal tidak terkendali!

Mengurangi entropi perangkat lunak tidak mudah

Sejauh ini bagus. Bahkan, semua ini tampak seperti pernyataan yang jelas; siapa pun yang pernah mendengar tentang pengembangan perangkat lunak mengetahui semua ini, setidaknya secara intuitif.

Mengapa utang teknis masih mengejutkan kita?

Ini karena meskipun kita tahu tentang perlunya refactor kode untuk mengurangi kebingungan, masih ada segudang kekuatan lain yang menguasai kita yang mencegah kita mengalokasikan waktu dan sumber daya yang diperlukan untuk melakukan refactoring dengan benar dan cukup sering. Ini berarti bahwa baik dalam basis kode kami dan semua lainnya, entropi perangkat lunak terus tumbuh.

Kita semua tahu hukum Moore, tetapi pikirkan tentang undang-undang Wirth versi Bill Gates:

Kecepatan perangkat lunak berkurang setengah setiap satu setengah tahun.
Bill Gates

Saya yakin bahwa entropi yang berkembang dari basis kode kami adalah kekuatan pendorong utama di balik pola ini.

Tingkat pertumbuhan entropi perangkat lunak terkait langsung dengan tingkat pertumbuhan faktor-faktor seperti teknologi, pasar perangkat lunak, perusahaan perangkat lunak dan literasi penulisan kode - dan masing-masing dari mereka tumbuh sangat cepat.

Sumber: The Emerging Future

Bayangkan tekanan dari ekspektasi ini terhadap tim pengembangan perangkat lunak. Ini adalah tren global yang serius, dan dapat dirasakan sebagai penghancuran oleh sekelompok orang yang relatif kecil. Ini hampir seperti meminta mereka untuk mengatasi gravitasi dan lepas landas, melambaikan tangan mereka.

Rekaman nyata dari tim pengembang yang melawan hutang teknis

Pada artikel berikutnya, kami akan mempertimbangkan microtren yang terus-menerus mendorong kami ke kebangkrutan teknis, serta bagaimana perusahaan perangkat lunak yang tumbuh cepat dapat melawannya. Tetap bersama kami!