it-swarm-id.com

Bagaimana saya bisa meyakinkan manajemen untuk berurusan dengan utang teknis?

Ini adalah pertanyaan yang sering saya tanyakan pada diri saya ketika bekerja dengan pengembang. Saya telah bekerja di empat perusahaan sejauh ini dan saya menyadari kurangnya perhatian untuk menjaga kode bersih dan berurusan dengan utang teknis yang menghambat kemajuan di masa depan dalam aplikasi perangkat lunak. Sebagai contoh, perusahaan pertama saya bekerja telah menulis database dari awal daripada menggunakan sesuatu seperti MySQL dan yang menciptakan neraka bagi tim ketika refactoring atau memperluas aplikasi. Saya selalu berusaha untuk jujur ​​dan jelas dengan manajer saya ketika dia membahas proyeksi, tetapi manajemen tampaknya tidak tertarik untuk memperbaiki apa yang sudah ada dan itu mengerikan untuk melihat dampaknya terhadap semangat tim.

Apa pendapat Anda tentang cara terbaik untuk mengatasi masalah ini? Apa yang saya lihat adalah orang berkemas dan pergi. Perusahaan kemudian menjadi pintu putar dengan pengembang masuk dan keluar dan membuat kode lebih buruk. Bagaimana Anda mengomunikasikan hal ini kepada manajemen untuk membuat mereka tertarik memilah hutang teknis ?

164
Desolate Planet

Ketika saya bertemu dengan bos saya untuk membahas hal ini, dia berkata saya harus memasukkan refactoring dalam semua perkiraan saya. Dia mengatakan itu bukan masalah yang ingin dia pikirkan. Sebaliknya, saya harus menanganinya.

Ini bukan masalah yang ingin dipikirkan manajemen pada umumnya. Mereka bukan insinyur, Anda. Jadikan ini bagian tak terucapkan dari semua perkiraan Anda, dan Anda akan menemukan bahwa utang teknis berkurang.

Itu tidak akan pernah sempurna sekalipun. Utang teknis, seperti utang kartu kredit, adalah investasi untuk mendapatkan pelanggan lebih cepat dan mendapatkan pangsa pasar lebih cepat dari pesaing Anda. Seperti halnya kredit, jika dikelola dengan baik, itu bisa membuat Anda cukup sukses.

194
jmort253

Seperti yang dikatakan Gandhi ketika ditanya apakah taktiknya akan bekerja dengan seseorang seperti Hitler. Dia berkata, "Itu akan sulit." Tapi saya pikir ada argumen yang adil bahwa jawabannya adalah "Tidak." Sayangnya, saya tidak berpikir apa yang Anda coba lakukan dapat dilakukan. Bukannya saya mencoba menjadi pesimis, tetapi saya mencoba untuk jujur.

Masalahnya bagi saya bukanlah manajer perlu meyakinkan. Yang lebih baik sudah mengerti bahwa utang bisa menjadi pembunuh jika tidak dikelola. Tetapi apakah mereka memahaminya atau tidak, apakah mereka manajer yang baik atau buruk, mereka semua menghadapi tekanan untuk memberikan, dan bahwa pengiriman dinilai oleh bos mereka berdasarkan tanggal. Kualitas hanya penting jika itu sangat buruk, dalam hal ini kesalahan pengembang, atau sangat baik, dalam hal ini kecemerlangan manajemen yang membuatnya terjadi. Kualitas hanya perlu "cukup baik."

Saya pikir saya suka apa yang dikatakan Renesis dalam jawabannya, karena itu adalah salah satu dari sedikit yang memahami bahwa manajemen berpikir sangat berbeda dari rekayasa. Dan saya pikir kita semua telah melihat perkembangan perusahaan menjadi berbasis-tanggal dan lebih dikelola oleh proyek sebagai lawan dari pelanggan dan fokus kualitas. Maksud saya, ini adalah perusahaan biasa, bukan perusahaan yang benar-benar kuat yang memiliki nyali untuk mengatakan "Itu akan dilakukan ketika sudah selesai" (seperti Apple Komputer atau Perangkat Lunak id - dan ya, saya pahami bahwa terkadang orang tidak bebas untuk mengambil pendekatan itu).

Tapi ada satu hal: perusahaan yang mengambil pendekatan kualitas-pertama ... apa yang Anda perhatikan tentang mereka? Itu benar, mereka dijalankan oleh para insinyur, bukan salesman, pemasar, manajer proyek atau akuntan. Pikirkan HP, Apple, id, Google, Microsoft, dan IBM. Semua dimulai dan dibuat sukses oleh para insinyur, bukan salesman, meskipun salesman jelas memainkan peran, dan saya yakin banyak yang akan berdebat jika Microsoft terkait dengan kualitas :). Dan dari mereka, yang menurun jauh dari kepemimpinan yang didorong oleh rekayasa. Ada banyak argumen dalam pernyataan itu, karena ada banyak perusahaan teknis yang akhirnya gagal karena ketidakmampuan untuk beradaptasi dengan perubahan zaman dan mengelola pertumbuhan mereka sendiri. Saya tidak melihat kepemimpinan berbasis rekayasa sebagai penyebab kegagalan itu, bagi saya itu adalah masalah keterampilan dan ketajaman bisnis yang independen dari seseorang yang menjadi pengembang atau akuntan. Saya pikir secara umum, bagaimanapun, bahwa ada dedikasi dalam rekayasa untuk kerasnya akuntabilitas dan disiplin yang menguntungkan perusahaan di mana teknik merupakan komponen.

Serius, lihat sekeliling. Kepemimpinan TI sangat kurang. Fokus selalu pada biaya dan waktu, dan jarang pada kualitas selama itu cukup baik. Para pemimpin TI jarang melapor kepada CEO lagi, sekarang selalu CFO. TI terjebak melakukan dukungan produksi dan semakin terikat pada manajer proyek yang fokusnya adalah pada potongan yang lebih kecil, lebih mudah dicerna, dan terukur, bukan perubahan signifikan nilai revolusioner (bukan berarti ini salah; membagi dan menaklukkan adalah hal yang baik, tetapi visi perlu ada di sana untuk gambaran besar).

Maaf sudah terlalu lama pada posting ini, tetapi pada akhirnya saya pikir pertanyaan Anda, tentang bagaimana membuat manajemen peduli dengan hutang teknis, seringkali lebih baik diselesaikan dengan mencari pemimpin yang tepat, daripada mengubah yang sudah ada. Menjelaskan hutang teknis kepada pemikir standar berarti mengubah fokus ke uang dan biaya, seperti yang dikatakan Renesis, dan saya pikir itu kehilangan banyak terjemahan. bahkan jika Anda berhasil dalam hal itu, hanya masalah jika pemimpin puncak perusahaan membelinya. Meyakinkan manajer menengah Anda untuk melakukan hal yang benar mungkin hanya akan membuatnya dipecat.

48
Bernard Dy

Hal pertama yang harus dilakukan adalah mengubah kata-kata. Menyebutnya "utang teknis" memberi manajemen gagasan bahwa mengizinkannya merupakan semacam investasi - padahal sebenarnya lebih seperti virus. (Aku seperti Dave Ramsey hutang teknis.)

Membiarkannya tidak dibayar datang dengan biaya besar yang tidak dapat dilihat atau dihitung dengan mudah.

Daftar masalah seperti berikut ini untuk manajemen:

  • Perkiraan fitur baru jauh lebih tinggi dari yang seharusnya. Atau, mustahil sama sekali.
  • Kode buruk memunculkan lebih banyak kode buruk
  • Daftar bug tumbuh bahkan jika pengembang selalu memperbaikinya
  • Anggota tim pergi (ini sendiri dapat menunjukkan bahwa ada masalah seperti yang dijelaskan dalam jawaban yang sangat bagus ini )
43
Nicole

Manajemen saya sebenarnya sudah mulai melakukan upaya serius untuk mengatasi utang teknis, yang merupakan salah satu alasan saya suka bekerja di sana, tetapi ini merupakan upaya jangka panjang dan tidak ada salahnya mengingatkan mereka mengapa upaya itu sepadan.

Salah satu cara saya tetap menekan adalah setiap kali saya diminta untuk memperkirakan, dan waktu bisa dihemat jika saya tidak harus berurusan dengan masalah utang teknis tertentu, saya sertakan dalam perkiraan saya. Misalnya, " Bug ini akan membuat saya 2-3 hari untuk melacak, tetapi jika kami sudah membahas 2 bug 'prioritas rendah' ​​lainnya yang telah berada dalam antrian selamanya, itu akan mungkin memakan waktu kurang dari satu. "Seringkali, responsnya adalah untuk terus maju dan memperbaiki yang lain saat Anda sedang melakukannya.

Saya juga setuju dengan jawaban lain tentang hanya mempertimbangkan perbaikan bagian dari pekerjaan Anda dan melakukannya saat Anda pergi jika tidak terlalu mengganggu. Tugas saya saat ini melibatkan penambahan beberapa kode yang dirancang sangat buruk. Daripada menambah kekacauan dengan menulis kode baru saya untuk mencocokkan, saya menghabiskan sedikit waktu di depan mengkonsolidasikan fungsi umum, jadi mengirim paket menjadi panggilan fungsi satu baris alih-alih terus-menerus mengulangi 15 baris copy-and- yang sedikit dimodifikasi tempelkan boilerplate.

Aku tahu pasti itu akan menyelamatkan kewarasan pemeliharaan beberapa lebih lanjut di jalan. Saya tahu karena saya adalah pengelola hari ini. Namun, saya juga percaya itu akan mempercepat tugas saya sendiri saat ini untuk mendapatkan fitur ini dan debug sekarang.

Teknik lain yang pernah saya gunakan di masa lalu dan harus saya lakukan lagi adalah simpan cabang DVCS refactoring di dalam pohon kerja yang terpisah untuk waktu henti saat Anda mengkompilasi, menunggu tes panjang, atau hanya perlu sedikit perubahan kecepatan saat Anda kehabisan bug. Selama Anda sesekali bergabung dari hulu sehingga Anda tidak menyimpang terlalu jauh, Anda bisa memakan waktu selama Anda ingin melakukan refactoring perubahan dengan sedikit upaya marjinal. 15 menit di sana-sini per hari dapat benar-benar bertambah seiring waktu.

30
Karl Bielefeldt

Anda dapat mencoba analogi kartu kredit. Tanyakan kepada mereka "apakah Anda merasa nyaman membiarkan laporan kartu kredit Anda tidak dibayar dalam waktu lama?"

Manajer memahami biaya dan manfaat, tetapi (biasanya) bukan istilah teknis yang digunakan oleh kami pengembang. Istilah "utang teknis" sudah diciptakan untuk membantu mengatasi hambatan komunikasi ini, tetapi Anda mungkin perlu mengartikulasikannya dengan lebih jelas. Sebagian besar manajer tahu betul (sering dari pengalaman sendiri) bahwa pembayaran kartu kredit yang sudah lewat tumbuh dengan tingkat bunga yang mengerikan sehingga sakit membuat mereka tidak dibayar. Ini dapat membantu mereka mendapatkan keseriusan masalah tentang entropi perangkat lunak.

Tetapi jika ini tidak meyakinkan mereka, cobalah untuk mengumpulkan bukti faktual dan membuat beberapa perhitungan. Misalnya. berapa biayanya bagi perusahaan - baik dalam bentuk uang tunai dan kehilangan waktu - untuk mengganti karyawan yang pergi.

20
Péter Török

Tidak ada yang akan memberikan uang untuk mengganti sesuatu yang berfungsi dengan sesuatu yang lain (dengan sedikit keberuntungan) juga berfungsi.

Yang dapat Anda lakukan adalah mengusulkan untuk menggantinya dengan sesuatu yang lebih bermanfaat, mis., Bundel pembayaran hutang teknologi menjadi peningkatan yang membawa manfaat bisnis instan dan nyata.

Tentu saja Anda harus terbuka tentang hal itu, kita tidak berbicara tentang "menyelinap dalam" proyek baru di sini.

Saya menemukan sisi lain, bahwa pengembang lebih sulit untuk ditangani. Pada dasarnya bermuara pada ini: untuk beberapa pengembang, memastikan kode Anda adalah kode terbaik yang dapat Anda buat adalah masalah kebanggaan profesional. Bagi yang lain, ini hanyalah pekerjaan lain dan tujuannya adalah menyelesaikannya dengan cepat dan pulang.

Tidak ada jumlah meyakinkan yang akan mengubah situasi itu, dan jika Anda memperkenalkan standar kualitas kode wajib, pengembang sembilan hingga lima Anda akan menemukan cara untuk bekerja sistem, sementara pengembang berdedikasi Anda pasti akan terganggu oleh seluruh prosedur (yang tidak mengarahkan mereka, tetapi Anda tidak bisa mengatakan bahwa pengembang X harus mematuhi aturan, sementara Y dapat melakukan apa pun yang diinginkannya).

Apa yang berhasil, tetapi masih bisa sangat membuat frustrasi adalah memiliki pengembang yang lebih berdedikasi dan berpengetahuan mengawasi basis kode, mungkin tradeoff yang baik antara maju dan merapikan apa yang sudah ada di sana.

12
biziclop

Faktanya adalah, di banyak perusahaan, terutama mengingat situasi ekonomi saat ini, setiap jam harus ditagih kepada seseorang.

Atau mereka turun, cepat.

Kecuali jika klien yang ada bersedia membayar untuk refactoring, yang sangat tidak mungkin kecuali jika disertai dengan peningkatan kinerja atau fitur yang signifikan. Maka itu tidak akan terjadi pada basis kode yang lebih lama. Anda mungkin dapat menyelundupkannya ke dalam anggaran untuk proyek-proyek baru, jika klien memiliki kantong dalam, tetapi kecuali Anda tidak perlu mengubah API di refactoring, itu tidak akan berguna untuk proyek-proyek yang lebih tua dan mungkin memperkenalkan situasi di mana perusahaan mendukung dua basis kode, yang menyebabkan sakit kepala dan biaya lebih lanjut.

Sebagai seorang insinyur, saya akan senang untuk memperbaiki kode lama, yang tidak lagi sesuai dengan tujuan, setiap kali sesuatu menjadi usang atau usang. Tetapi sebagai MDs saya di semua perusahaan tempat saya pernah bekerja mengatakan kepada saya: "Siapa yang akan membayar?"

12
Orbling

Saya selalu berusaha membersihkan saat saya pergi. Saya belum selesai sampai kode bersih. Masalah dengan hutang teknis adalah kebanyakan orang tidak memahaminya. Cara terbaik untuk mengatasinya adalah dengan tidak mengakumulasikannya. Jika manajer Anda memercayai pengembang Anda untuk memutuskan bagaimana menyelesaikan masalah, Anda bisa menjadikan kode hygiene bagian dari setiap tugas pemrograman. Jika Anda tidak pernah memeriksa kode yang buruk, Anda tidak menumpuk hutang. Jika Anda juga mengikuti Aturan Pramuka (selalu biarkan kode lebih bersih daripada yang Anda temukan) utang Anda yang ada akan hilang perlahan.

Saya tidak melihat refactoring sebagai tugas yang terpisah dari penerapan fitur. Itu adalah bagian integral darinya.

12
EricSchaefer

Jika Anda berurusan dengan manajer non-teknis, itu akan membantu jika Anda bisa memasukkan diskusi Anda ke dalam istilah yang mereka pahami. Jika Anda dapat membuat kasus realistis untuk ROI positif pada pekerjaan yang dihabiskan untuk membayar utang teknis, Anda mungkin mendapatkan suatu tempat. Latihan itu akan tergantung pada keadaan Anda, tetapi contohnya mungkin seperti ini:

Menganalisis berapa banyak waktu yang dihabiskan pengembang untuk membantu Dukungan dengan masalah produksi, kemudian membuat kasus bahwa memperbaiki kode lama akan A. mengurangi jumlah masalah dukungan, B. membuatnya lebih mudah bagi Dukungan untuk menyelesaikan masalah tanpa meningkatkan Pembangunan, dan C. kurangi waktu yang dihabiskan Pengembangan untuk masalah produksi ketika mereka muncul. Masukkan dalam bentuk dolar yang dihemat dengan tidak membuat pengembang terikat melakukan pekerjaan dukungan. Juga tunjukkan bahwa setiap jam pengembang menghabiskan dukungan untuk melakukan adalah "double whammy" karena Anda tidak hanya membayar pengembang untuk melakukan dukungan, tetapi Anda juga membakar biaya peluang dari apa yang pengembang dapat lakukan (menambahkan fitur baru, dll. .)

Ya, beberapa angka akan menjadi voodoo/smoke-and-mirror ... tidak apa-apa, rahasia kotor manajemen adalah bahwa mereka tah bahwa sebagian besar angka yang mereka selipkan adalah total B.S. Selama Anda memberi mereka sesuatu yang tampaknya konkret untuk dikerjakan, sehingga mereka bisa mendapatkannya di kepala mereka, Anda memiliki peluang untuk bertarung.

7
mindcrime

Setelah penjelasan hutang teknis ini, manajemen Anda harus diyakinkan untuk melunasinya:

Bayangkan Anda memiliki dapur yang sangat kotor dan penuh sampah. Sebelum menyiapkan makanan, Anda harus terlebih dahulu menghabiskan satu jam membersihkan. Dan itu seperti itu setiap kali Anda ingin makan. Juga, ketika menyiapkan makanan, Anda harus ekstra hati-hati, untuk memastikan omong kosong tidak jatuh dalam makanan Anda.

Dapur adalah kode Anda, makanan adalah produk Anda, dan makan adalah penjualan produk Anda.

Jika mereka mampu menunggu lebih lama untuk perubahan diimplementasikan, tanpa jaring unit test, maka ada sesuatu yang salah di perusahaan Anda.

6
BЈовић

Itu harus menjadi argumen yang sangat meyakinkan, dalam hal produk asli dan kasus bisnis, bahwa saya tidak dapat menggunakan uang itu sekarang untuk melakukan sesuatu yang lebih penting bagi saya. Suka atau tidak, manajemen Anda atau pelanggan Anda membayar untuk ini dan Anda harus dapat menjual ke alias meyakinkan mereka.

Mari kita ulangi ini untuk memposisikan diri Anda sebagai pelanggan. Permainan peran lama yang bagus.

Misalkan Anda membeli kulkas. Dan Anda dapat membeli kulkas seharga $ 1000 yang bekerja OK dari Acme Corp. Atau kulkas seharga $ 2000 dari Acme Deluxe Fridges yang tampak sama di luar dan memiliki spesifikasi teknis yang sama, tetapi memiliki biaya perawatan yang lebih rendah karena arsitektur internal yang lebih bersih.

Sebagai pelanggan, mana yang akan Anda beli sendiri?

Dan apa yang menurut para insinyur Acme Deluxe adalah jawaban yang lebih baik?

4
jasonk

" Hutang teknis " dapat menjadi subjek yang rumit untuk dipresentasikan kepada manajemen karena mereka mungkin tidak melihat perlunya. Pertanyaannya dapat dibingkai sebagai apakah ada juara di perusahaan untuk menyatakan, "Lihat, kami mengambil X% waktu untuk mengerjakan hutang teknis di sini. Beri kami 3 bulan untuk menunjukkan kepada Anda ini berfungsi dengan baik," atau sesuatu serupa. Ada klaim terhadap otonomi di sana tetapi juga kerangka waktu karena jika tidak manajemen mungkin bertanya-tanya berapa lama sampai mereka melihat beberapa hasil yang merupakan wilayah yang agak berbahaya.

Poin pertama adalah apakah mereka melihat ini sebagai masalah atau tidak. Jika orang dengan penglihatan buruk tidak tahu apa-apa tentang kacamata dan jenis perubahan apa yang dapat mereka berikan, bagaimana mereka memahami mengapa tes mata bisa berharga? Gagasan yang sama di sini di mana subjeknya agak teknis dan sayangnya tidak mudah diukur.

3
JB King

Anda harus berhenti mengeluh tentang hal itu.

Inilah alasannya:

  1. Mereka tidak pernah berencana untuk menggunakan perangkat lunak lebih dari satu tahun
  2. hanya buang-buang waktu saja jika rencana mereka adalah membuangnya setelah itu
  3. ada beberapa masalah nyata yang perlu diperbaiki sekarang
  4. programmer hanya perlu belajar untuk berurusan dengan perawatan, bahkan jika itu tidak selalu menyenangkan
  5. mengeluh bahwa Anda tahu lebih baik apa yang perlu dilakukan adalah sombong - orang lain membuat keputusan, dan Anda harus senang tentang hal itu
  6. Mereka tetap mempercayai Anda untuk menulis kode yang baik

Jadi cara terbaik ke depan adalah:

  1. Ketika mereka memberi Anda tugas baru, cobalah untuk mengimplementasikannya sebaik mungkin dalam waktu yang diberikan
  2. Tulis dengan sempurna pertama kali. Jika Anda perlu mengubahnya setelah itu, Anda membuat kesalahan pertama kali dan setiap perubahan selalu salah arah - dan ini merupakan kesempatan belajar bagi programmer ketika Anda membuat kesalahan.
  3. Jangan meminta waktu ekstra untuk itu, Anda tidak akan mendapatkannya, ada tenggat waktu yang Anda tahu.
2
tp1

Saya kira Anda tidak pernah terlibat dalam proyek untuk menulis ulang/mengganti atau bahkan meningkatkan dan sistem yang ada.

Ini adalah beberapa proyek tersulit untuk diselesaikan dengan sukses. Beberapa masalah yang akan Anda temui adalah:

  1. Aturan bisnis hilang dalam waktu.
  2. Dokumentasi dan implementasi sama sekali tidak sinkron.
  3. Apa yang Anda lihat sebagai bug yang dilihat pengguna sebagai fitur.
  4. Sebaliknya banyak "fitur" akan dianggap cacat oleh pengguna.
  5. Anda tidak akan mendapatkan pengguna membeli - mereka akan menganggap "pencarian fakta" Anda sebagai "kutu buku yang mengajukan pertanyaan bodoh", mereka akan menganggap upaya pengujian sebagai pemborosan waktu, mereka akan bersikeras untuk menambahkan fitur baru sehingga memperpanjang proyek akan akan sudah terlambat.
  6. Kemungkinannya adalah kode sumber tidak cocok 100% dengan executable yang berjalan.
  7. Sementara departemen Anda mengacaukan pengembangan refactoring yang sebenarnya diinginkan bisnis tidak dilakukan.
  8. Kemungkinannya adalah re-factoring Anda akan melibatkan "antarmuka yang lebih bersih dan lebih baik" sehingga menyeret proyek lain ke dalam rawa terlambat pengiriman dan pengujian gagal.
  9. Setelah proyek dikalengkan (lebih dari 50% dari upaya ini gagal sepenuhnya), Anda akan kehilangan semua kredibilitas - Anda harus pindah ke perusahaan lain di kota lain untuk menemukan seseorang yang siap mendengarkan Anda juga.
  10. Jika proyek "berhasil" semua orang akan mengingat mimpi buruk itu - Anda akan .......

Saya mendorong Anda untuk menghindari proyek penulisan ulang/refactoring seperti wabah, mereka dapat menjadi beberapa pengalaman yang paling membuat putus asa dalam karir profesional apa pun.

Ada banyak hikmat dalam kalimat "Jika tidak rusak jangan memperbaikinya".

2
James Anderson

Setelah terlibat dalam penulisan ulang utama, (bukan hanya refactor), saya dapat setuju bahwa meminta orang keuangan untuk menyetujui proyek adalah salah satu rintangan utama. Mengatasi rintangan itu mengharuskan saya untuk menulis, menyajikan, dan membela laporan yang menunjukkan sejumlah masalah yang berarti bahwa bisnis perusahaan akan mati di air dalam waktu dekat hingga jangka menengah.

Faktor-faktor kunci dalam membuat perjanjian untuk terus maju:

  • Kode yang ada berada dalam rantai alat yang tidak lagi didukung, (MicroPower Pascal), yang hanya berjalan pada platform pengembangan yang hampir tidak didukung, (PDP11-23).
  • Menemukan pengembang yang dapat mengerjakan alat dan target menjadi hampir mustahil.
  • Perangkat keras target tidak lagi tersedia jika suku cadang diperlukan dan produsen semakin enggan menyediakan layanan perbaikan.
  • Masalah dalam kode menghasilkan ketidakpuasan pelanggan yang mudah diidentifikasi dan biaya servis langsung.
  • Menambahkan fitur baru atau bahkan perbaikan bug menjadi hampir mustahil karena keterbatasan perangkat keras target yang mengakibatkan kebutuhan untuk memperbaiki area lain sehingga memberikan ruang ketika menangani masalah.
  • Dengan waktu pembangunan 8 jam, pengembangan dan pengujian setiap perubahan itu mahal.

Laporan tersebut merinci masalah, dengan perkiraan biaya yang sedang berlangsung, dan menawarkan 3 opsi:

  1. Bekukan di tempat kami mungkin dengan bahkan perbaikan bug tidak dalam waktu dekat.
  2. Optimalkan kode hanya untuk ruang, tanpa memperhatikan kemampuan pemeliharaan, menunjukkan bahwa siapa pun yang berusaha mempertahankan kode yang dioptimalkan harus lebih pintar daripada siapa pun yang melakukan optimasi.
  3. Implement ulang, dengan testabilitas dan perawatan sebagai faktor tinggi, dalam standar industri, diajarkan secara luas, bahasa, (ANSI C), pada perangkat keras COTS baru, berbiaya rendah, (PC-104), dengan beberapa vendor tersedia dengan in-house kartu antarmuka yang dirancang untuk memungkinkannya bekerja dengan perangkat keras yang ada yang tersisa. Menambahkan serangkaian fitur baru terbatas sebagai bagian dari pengembangan seperti penyimpanan non-volatil, pengawas waktu untuk menyediakan restart otomatis dalam kondisi kesalahan beberapa unit mengalami crash beberapa kali sehari dan membutuhkan panggilan layanan £ 40) keluar untuk mengatur ulang, diagnostik yang lebih baik dalam proses.

Setelah mendapat opsi ke-3 untuk kontrak ke-3, kontrak 3 bulan saya berubah menjadi kerja keras selama 3 tahun, keduanya mengembangkan perangkat lunak dan perangkat keras baru, tetapi dengan hasil yang sangat baik.

Untuk kasus-kasus dengan utang teknis yang tidak terlalu ekstrem, saya cenderung mengadopsi apa yang saya sebut refraktor gerilya:

Ketika ada masalah dengan modul tertentu:

  1. Tulis satu set tes yang menunjukkan masalah yang juga kemungkinan gagal tanpa refactoring
  2. Refactor sebagai bagian dari pengembangan menunjukkan bahwa tes masih gagal.
2
Steve Barnes

Untuk kehidupan saya, saya tidak dapat mengerti mengapa beberapa orang begitu takut terhadap perubahan - itu berbau kurang percaya diri pada kemampuan Anda sendiri.

Saya menonton pertunjukan semalam di Taman Nasional Yosemite dan dikatakan bahwa dari tahun 1940 hingga akhir 1990-an tidak ada satu pun pohon Sequoia baru yang tumbuh. Ditemukan bahwa alasan mengapa ada kebijakan ketat untuk tidak membiarkan kebakaran hutan membakar dan bahwa kerucut pinus Sequoia membutuhkan panas dari api untuk membuka dan melepaskan bijinya.

Anda lihat, api setiap sepuluh tahun atau lebih itu sehat. Itu membersihkan semua kayu mati yang terakumulasi dan semak duri untuk menjaga kesehatan pohon (proses) yang ada dan memberikan ruang bagi yang baru (fitur).

Saya sedang mengerjakan sebuah proyek saat ini yang memiliki kasus yang jelas untuk dibangun kembali: Perangkat lunak warisan seluruhnya ditulis menggunakan formulir web .NET. Hampir semua logika bisnis digabungkan dengan logika tampilan tag HTML/server dan tidak dapat diperluas ke aplikasi lain sekarang karena bisnis telah berkembang.

Manajemen berada di belakang tugas karena mereka memiliki jumlah kepercayaan yang sesuai pada pengembang mereka yang, saya sadari, merupakan kemewahan yang langka.

Ya, tanyakan pada diri Anda apakah pembangunan kembali benar-benar diperlukan. Lakukan yang terbaik untuk menggunakan kembali kode yang ada yang berfungsi di mana Anda bisa. Integrasikan kode itu ke dalam pembangunan kembali jika perlu. Hanya saja, jangan biarkan siapa pun meyakinkan Anda bahwa takut membuat perubahan yang berani adalah satu-satunya cara untuk eksis sebagai pengembang perangkat lunak.

Semoga berhasil!

1
Matt Cashatt

Anda perlu memberi alasan keuangan kepada manajemen Anda untuk berurusan dengan utang teknis, dan kerangka kerja untuk mengelola pengurangan utang teknis itu.

Mempertahankan roadmap teknologi adalah salah satu kerangka kerja tersebut. Memulai dengan peta jalan akan membantu Anda mencegah Anda menumpuk utang teknis, dan juga dapat membantu Anda mengurangi utang yang ada juga.

Banyak proyek jangka panjang yang sukses telah mengaitkan komite pengarah dan peta jalan untuk memandu pengembangan. Ini sangat membantu ketika ada banyak tim pengembangan dan pemangku kepentingan yang terlibat.

Saran saya adalah agar Anda mendiskusikan strategi ini dengan manajer Anda (dan jika mungkin mereka yang membuat keputusan tentang di mana uang dibelanjakan).

Pendekatan umum untuk membuat dan mengelola roadmap sangat mudah, tetapi memang membutuhkan dukungan dari tim manajemen Anda. Pertama, tentukan tujuan. Tentukan elemen utang teknis, dan kembangkan arsitektur sistem target yang mengurangi elemen utang teknis Anda. Ingat, itu tidak harus sempurna, hanya bisa diterapkan dan lebih baik dari apa yang Anda miliki saat ini. Mempertimbangkan perangkat lunak akun, alat pengembangan, platform perangkat keras, fitur baru utama yang dapat ditambahkan ke sistem. Lakukan analisis biaya. Jika Anda memiliki arsitektur yang diinginkan, apa manfaat nyata dari melakukan refactoring? (Manfaat akan mencakup pengurangan waktu pengujian, produk perangkat lunak yang lebih andal, siklus pengembangan yang lebih dapat diprediksi, dll.) Jika Anda dapat menunjukkan manfaat yang cukup untuk melakukan refactoring, Anda bisa mendapatkan dukungan manajemen.

Setelah Anda memiliki peta jalan dan dukungan manajemen, kembangkan serangkaian langkah (juga disebut rencana) yang perlu Anda ambil untuk mencapai kondisi yang diinginkan ini. Mungkin merupakan ide yang baik untuk menyusun komite pengarah yang memelihara peta jalan, melatih dan mendidik tim pengembangan tentang peta jalan, dan secara berkala meninjau perubahan untuk integritas arsitektur.

Peta jalan benar-benar bermanfaat, dan mungkin pertanyaan ke-13 tentang Tes Joel seharusnya adalah "Apakah Anda memiliki peta jalan?"

Berikut adalah video jam pertama dari sesi peta jalan Red Hat Linux baru-baru ini .

1
Jay Elston