Bagaimana saya bisa meyakinkan manajemen untuk berurusan dengan utang teknis?


158

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-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 utang teknis ?


5
"bekerja dengan pengembang" "mengomunikasikan hal ini kepada manajemen" Apa yang Anda tanyakan? Pengembang atau manajer? Perilaku siapa yang ingin Anda ubah?
S.Lott

45
Utang teknis seperti utang finansial - dalam jangka panjang akan jauh lebih mudah untuk tidak mengakumulasinya. Bayar semua tagihan teknis Anda seminggu sekali.
Lawrence Dol

7
Mike> Saya pikir Anda hidup di dunia yang tidak terlalu ketat karena tenggat waktu dan anggaran terbatas mendominasi dunia tempat saya tinggal. Jika perangkat lunak tidak beradaptasi dengan baik dengan kebutuhan di masa depan dan membutuhkan banyak pekerjaan untuk diperbaiki, maka manajemen seringkali lebih peduli dengan pengabaian. dan terus perbaiki fitur. Sekarang banyak rekan kerja saya telah bekerja di menempatkan timesheets di tempat sehingga pengembang perlu mencatat pekerjaan mereka dan jika waktu tidak diinvestasikan di mana manajemen melihat bisnis potensial, maka Anda membuang-buang waktu Anda.
Desolate Planet

4
Saya kira Anda bisa mengatakan itu masalah dengan manfaat jangka pendek vs manfaat jangka panjang. Jika tim perangkat lunak merapikan suatu sistem sedemikian rupa sehingga fitur-fitur baru membutuhkan waktu kurang dari satu jam untuk diimplementasikan, bukan satu hari, itu adalah manfaat langsung. Jika manajemen melihat Anda mencoba memperbaiki kode dan menentang apa yang mereka inginkan, Anda menjadi sedikit pemberontak di mata mereka. Saya benar-benar tidak tahu apa solusi terbaik, tetapi sepertinya ini adalah masalah yang umum dan saya telah melihat apa yang terjadi pada tim.
Desolate Planet

3
Scott> Untuk menjawab pertanyaan, itu adalah sikap manajemen yang ingin saya ubah. Pengembang tahu kode dan memiliki pengalaman langsung tentang kode apa yang diperbaiki untuk mempermudah. Dalam pekerjaan sebelumnya ketika kami merilis versi baru aplikasi, jumlah bug terus meningkat pada tingkat yang mengerikan. Saya sudah berusaha keras untuk mendapatkan strategi pengujian, tetapi sering terasa seperti penyebab yang hilang.
Desolate Planet

Jawaban:


191

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.


30
pengalaman saya umumnya sejalan dengan ini. Utang teknis dibersihkan karena fitur baru ditambahkan. Kadang-kadang perkiraan untuk perbaikan / fitur 'terkait' tertentu diisi untuk memasukkan pembersihan hal-hal ini.
Ken Henderson

4
+1 Anda membagikan sentimen saya dengan tepat ... kecuali Anda mengekspresikan diri Anda lebih diplomatis;)
Michael Brown

7
Jawaban yang bagus. Saya belum melihat bisnis yang senang menandatangani proyek 'refactoring' yang tidak akan menghasilkan manfaat bagi pelanggan, hanya kode yang lebih rapi. Refactor-as-you-go.
JBRWilkinson

7
"Ketika saya bertemu dengan bos saya untuk membahas hal ini, dia berkata saya harus memasukkan refactoring dalam semua perkiraan saya." - Ini adalah sikap yang saya ambil dan pendirian banyak pengembang dalam tim yang telah saya kerjakan. Namun, ketika 9 hingga 5 pengembang ini seperti yang kami sebut prihatin dengan ulasan dan kenaikan gaji, mereka tidak akan menciptakan lebih banyak pekerjaan untuk diri mereka sendiri. Mereka akan mengikuti apa pun yang menurut manajemen, itulah yang membayar mereka.
Desolate Planet

8
@ jmort253: ada satu (sedikit) masalah dengan kebijakan yang dinyatakan sangat baik ini -> itu tidak mungkin untuk perubahan ekstensif (yaitu, mengubah database seperti yang dikatakan oleh OP). Itu harus ditangani secara eksplisit.
Matthieu M.

48

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 menyukai 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 punya nyali untuk mengatakan "Itu akan dilakukan ketika sudah selesai" (seperti Apple Computer atau id Software - dan ya, saya mengerti bahwa kadang-kadang orang tidak bebas untuk mengambil pendekatan itu).

Tetapi ada satu hal: perusahaan yang mengambil pendekatan kualitas-pertama ... apa yang Anda perhatikan tentang mereka? Itu benar, mereka dijalankan oleh 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 memperdebatkan apakah 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 tidak mampu beradaptasi dengan perubahan zaman dan mengelola pertumbuhan mereka sendiri. Saya tidak melihat kepemimpinan berbasis teknik sebagai penyebab kegagalan itu, bagi saya itu ' s masalah keterampilan dan ketajaman bisnis yang tidak tergantung pada 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 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 dalam 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 utang 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 akan menjadi masalah jika pemimpin teratas di perusahaan membelinya. Meyakinkan manajer menengah Anda untuk melakukan hal yang benar mungkin hanya akan membuatnya dipecat.


43

Hal pertama yang harus dilakukan adalah mengubah kata-katanya. Menyebutnya "utang teknis" memberi gagasan kepada manajemen bahwa mengizinkannya adalah semacam investasi - padahal sebenarnya itu lebih mirip virus. (Saya seperti Dave Ramsey dari utang 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 bertambah bahkan jika pengembang selalu memperbaikinya
  • Anggota tim pergi (ini sendiri dapat menunjukkan bahwa ada masalah seperti yang dijelaskan dalam jawaban yang sangat baik ini )

7
+1, meskipun saya pikir peluru terakhir adalah "Anggota tim yang baik / terbaik akan pergi"
Ken Henderson

12
Utang teknis bit adalah investasi kadang-kadang. Jika Anda berpacu dengan perusahaan lain dan yang meluncurkan pertama mendapatkan pasar untuk diri mereka sendiri, maka masuk akal untuk membuat pintasan dalam kode untuk memulai lebih cepat. Tidak ada yang akan peduli bahwa Anda memiliki kode sempurna jika Anda memiliki nol pelanggan yang membayar.
quant_dev

3
@quant_dev jika Anda melihat ini sebagai dikotomi antara "lebih cepat" dan "kode sempurna" maka tentu saja Anda akan berpikir seperti itu. Tidak ada alasan mengapa jalan pintas tidak dapat secara teknis sehat dalam hal ini mereka tidak dianggap sebagai hutang teknis.
Nicole

2
@Renesis "Tidak ada alasan mengapa pintasan tidak dapat secara teknis terdengar" - itu tidak benar.
quant_dev

3
Dan kadang-kadang itu bukan utang teknis sama sekali, itu hanya kekacauan: sites.google.com/site/unclebobconsultingllc/…
TrueWill

30

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 untuk 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 memasukkannya dalam perkiraan saya . Misalnya, " Bug ini akan memakan waktu 2-3 hari untuk saya lacak, tetapi jika kami telah menangani 2 bug 'prioritas rendah' ​​lainnya yang telah berada dalam antrian selamanya, mungkin akan memakan waktu kurang dari satu. " Seringkali, jawabannya 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 fungsionalitas umum, jadi mengirim paket menjadi panggilan fungsi satu baris alih-alih terus-menerus mengulangi 15 baris salinan dan modifikasi yang sedikit dimodifikasi tempelkan boilerplate.

Aku tahu pasti itu akan menyelamatkan kewarasan beberapa pemelihara lebih jauh 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 menyimpan cabang DVCS refactoring di sekitar pohon kerja terpisah untuk waktu henti saat Anda sedang menyusun, menunggu tes panjang, atau hanya perlu perubahan kecepatan untuk sedikit ketika 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.


20

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 (seringkali dari pengalaman sendiri) bahwa pembayaran kartu kredit yang sudah lewat tumbuh dengan tingkat bunga yang mengerikan sehingga menyakitkan untuk membiarkan 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.


12

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

Apa yang dapat Anda lakukan adalah mengusulkan untuk menggantinya dengan sesuatu yang lebih bermanfaat, yaitu menggabungkan 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 dapat mengatakan bahwa pengembang X harus mematuhi aturan, sementara Y dapat melakukan apa pun yang diinginkannya).

Apa yang berhasil, tetapi masih bisa sangat frustasi 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.


5
+1 Namun pengembang 9-5 itu, Anda menginginkan pintu putar untuk mereka, idealnya dengan beberapa bentuk akselerator.
Orbling

3
@Orbling: +1. Jika mereka tidak cukup peduli mereka benar-benar harus bekerja di tempat lain. Para pengembangnya yang hebat datang kepada Anda dengan "Saya baru saja mendapat ide ini ...".
cepat

3
@Orbling Di bidang pengembangan tertentu mereka bisa berguna. Saya sama sekali bukan penggemar "keangkuhan pengembang", tetapi Anda harus menemukan niche semua orang agar mereka dapat digunakan. Yang terburuk yang bisa Anda lakukan adalah menganggap semua orang seperti Anda.
biziclop

Secara pribadi, saya pikir industri ini kelebihan pegawai. Di mana saya berdasarkan sebagian besar pekerjaan perangkat lunak mendapatkan 300 kandidat yang baik melamar hari ini. Dengan tingkat persaingan seperti itu, seorang pengusaha mampu mempekerjakan pengusaha yang bekerja lebih keras dan lebih baik daripada rata-rata.
Orbling

"Gulung upgrade ke refactoring untuk menawarkan manfaat nyata (nilai jual)" adalah apa yang saya dengar dari Kepala Arsitek kami sehingga saya harus melakukan yang kedua.
Mario T. Lanza

12

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 menyelinap masuk ke dalam anggaran untuk proyek-proyek baru, jika klien memiliki kantong besar, 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 benar-benar cocok untuk tujuan, setiap kali sesuatu menjadi usang atau usang. Tetapi sebagai MDs saya di semua perusahaan saya pernah bekerja di mengatakan kepada saya: "Siapa yang akan membayar?"


12

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 dengan lambat.

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


5
Saya sangat setuju: "Hutang teknis seperti hutang finansial - dalam jangka panjang akan jauh lebih mudah untuk tidak mengakumulasikannya. Bayar semua tagihan teknis Anda seminggu sekali"
Lawrence Dol

7

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 tahu bahwa sebagian besar angka yang mereka angkut adalah total BS. Selama Anda memberi mereka sesuatu tampaknya konkret untuk dikerjakan, sehingga mereka bisa mendapatkannya di kepala mereka, Anda memiliki peluang untuk bertarung.


6

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.


4

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?


3
Saya mengalami kesulitan menentukan posisi Anda dalam hal ini. Saya pikir jawaban Anda adalah "itu tergantung pada apa yang diinginkan pelanggan". Masalahnya adalah, tidak setiap pelanggan memahami bahwa kulkas berbiaya lebih rendah akan bocor, kotoran buruk dari bagian freezer, membuat suara keras, dan akhirnya berhenti bekerja setelah 5 tahun, sementara yang lain akan berjalan lancar dan tenang selama 20 tahun dan tidak akan diganti sampai dianggap tidak sesuai gaya oleh pemilik yang akan dijual kembali dengan imbalan model baru. Tetap saja, saya suka pertanyaan yang Anda ajukan. Pikiran itu memprovokasi. +1
jmort253

Baris pertama - "Itu harus menjadi argumen yang sangat meyakinkan [] bahwa saya tidak dapat menggunakan uang itu sekarang untuk melakukan sesuatu yang lebih penting bagi saya." Saya menggunakan contoh kulkas sebagai terus terang, saya tidak peduli tentang apa yang terjadi di dalam kulkas saya. Saya hanya ingin hasil. (makanan dingin dengan harga wajar). Terus terang, saya tidak peduli jika para insinyur kulkas berpikir itu adalah produk yang lebih baik secara internal. Saya mungkin berkonsultasi dengan mereka tetapi itu benar-benar bukan keputusan mereka.
jasonk

3

" Hutang teknis " dapat menjadi subjek yang sulit untuk disampaikan kepada manajemen karena mereka mungkin tidak melihat perlunya. Pertanyaannya dapat dibingkai sebagai apakah ada juara di perusahaan untuk menyatakan, "Lihat, kami mengambil waktu X% 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.


Saya setuju dengan ini sepenuhnya dan semakin banyak menemukannya. Baru-baru ini, saya telah mengumpulkan daftar cacat yang telah dibuka kembali karena perbaikan yang tepat tidak dilakukan atau cacat yang serupa. Semoga para pengembang menghabiskan waktu. Kadang-kadang mereka melakukannya, kadang-kadang tidak, tetapi data semacam ini adalah fondasi yang berguna untuk menunjukkan kepada manajemen bagaimana produk yang tidak sehat memengaruhi bisnis mereka.
Desolate Planet

2
Di tempat kerja saya saat ini, lembur dialokasikan untuk alasan yang salah. Jika waktu diinvestasikan untuk menjaga aplikasi tetap sehat alih-alih masalah pemadaman kebakaran, uang akan dihemat pada waktu lembur dan pengembang akan lebih diberdayakan daripada kehabisan tenaga dan kesal pada manajemen.
Desolate Planet

Tetapi manajemen (dalam banyak kasus dengan benar!) Melihatnya dengan cara ini. Saya memiliki magimix tahun 1980-an yang masih berfungsi dan Anda menyuruh saya untuk menggantinya hanya karena warnanya sudah tua dan warnanya sudah ketinggalan zaman!
James Anderson

2

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 untuk 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 percaya 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 menuju arah yang salah - 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.

3
Sebagian besar saya setuju kecuali bahwa sudah diketahui bahwa bahkan perangkat lunak jelek memiliki kecenderungan untuk bertahan lebih lama dari yang diharapkan penciptanya. Tapi Anda benar, lebih baik tidak mengeluh. Alih-alih, jika Anda melihat beberapa anjak piutang skala terbatas yang akan membantu kelengkapan kode, mungkin layak untuk melanjutkan dan membuat perubahan TANPA PERIZINAN selama pemeliharaan / perbaikan bug (dan menimbulkan risiko melakukannya).
Angelo

@ Angelo - Apakah tidak lebih baik menyuarakan keprihatinan Anda daripada membiarkan tim menderita dalam kesunyian? Saya telah melihat apa masalah ini terhadap semangat tim dan juga dengan jumlah waktu / uang yang terbuang untuk kerja lembur. Saya tidak melihatnya sebagai "erangan". Anda hanya menunjukkan risiko proyek dan jika ide-ide Anda dapat mempercepat waktu pengiriman dan merampingkan proses, lalu mengapa tidak setidaknya mencoba menyuarakan keprihatinan Anda? Jika ini jatuh dari telinga tuli, maka setidaknya Anda tahu di mana Anda berdiri.
Desolate Planet

2
Anda harus mengeluh tentang hal itu dengan keras , jika tidak, itu salah Anda jika kode orang lain rusak ("Anda tahu ini berantakan dan tidak memberi tahu siapa pun?"). Berdiri dan maju "Hei bos, omong kosong ini cepat atau lambat akan memukul penggemar" sangat penting untuk menjaga fungsional tim dev.
Alex

1

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 menambahkan fitur baru sehingga memperpanjang proyek 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.

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


1
"Saya rasa Anda tidak pernah terlibat dalam proyek untuk menulis ulang / mengganti atau bahkan meningkatkan dan sistem yang ada" - Salah, 7 tahun.
Desolate Planet

1
Saya sepenuhnya setuju bahwa menulis ulang lengkap sering kali merupakan bencana. Tapi saya punya tiga contoh selama 8 tahun terakhir dalam karir saya. Salah satunya adalah slog panjang yang mengakibatkan kami mampu mempertahankan produk lebih baik tetapi tidak memberikan nilai bisnis; yang lain adalah penulisan ulang singkat yang merupakan keberhasilan total; yang ketiga adalah keputusan untuk tidak menulis ulang, yang akhirnya membunuh perusahaan. Pilih racun Anda.
Tom Harrison Jr

1

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

Saya menonton pertunjukan tadi malam 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 tahu, 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 .NET webforms. Hampir semua logika bisnis berbaur dengan logika tampilan tag / server HTML 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
bagaimana ini menjawab pertanyaan yang diajukan, "Bagaimana Anda mengomunikasikan hal ini kepada manajemen untuk membuat mereka tertarik dalam memilah utang teknis?"
Agak

1
@gnat: Bagaimana sebagian besar "jawaban" menjawab pertanyaan itu secara langsung? Lihat, misalnya, jawaban oleh James Anderson, tp1, atau jawaban di bagian atas dengan suara terbanyak. Tetapi untuk menjawab pertanyaan Anda, saya memberikan analogi alternatif yang bisa digunakan OP. Menurut saya Anda tidak setuju dengan pendapat saya tentang masalah ini. Itu baik-baik saja, tetapi tidak ada alasan untuk membatalkan.
Matt Cashatt

1
per bacaan saya, jawaban teratas yang Anda referensikan tampaknya langsung menjawab jawaban yang diajukan, berdasarkan pengalaman yang relevan "Ketika saya bertemu dengan bos saya untuk membahas ini ..." Adapun pendapat Anda, saya cenderung setuju dengan itu, tetapi saya memilih berdasarkan pada kualitas konten, bukan pada apakah saya mendukung pendapat tertentu atau tidak setuju. Model pemilihan Q&A Stack Exchange cukup buruk ketika (salah) digunakan untuk jajak pendapat
agas

1
Saya sarankan membacanya lagi, kalau begitu. Menjelaskan percakapan dengan bos seseorang mengenai metode untuk menutupi utang teknis dengan menambahkan estimasi untuk pekerjaan di masa depan tidak menjawab pertanyaan, "Bagaimana Anda mengomunikasikan hal ini kepada manajemen untuk membuat mereka tertarik dalam memilah utang teknis?" antara. Meskipun demikian, saya tidak memilih jawaban karena itu ditambahkan ke percakapan. Jadi, yang berhasil Anda lakukan adalah membungkam pendapat tentang masalah yang Anda setujui tanpa alasan substansial. "Pemrogram" harus menjadi tempat di mana kita dapat berbicara. Tidak semuanya biner.
Matt Cashatt

1

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

Mempertahankan peta jalan teknologi adalah salah satu kerangka kerja tersebut. Memulai dengan peta jalan akan membantu Anda mencegah Anda menumpuk pada 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 membahas 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 dapat memperoleh 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 pada Tes Joel seharusnya adalah "Apakah Anda memiliki peta jalan?"

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


1

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 tidak mungkin 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 adalah 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 rawatan, menunjukkan bahwa siapa pun yang mencoba 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 seperangkat 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 untuk mengatur ulang , diagnosa yang lebih baik dalam proses.

Setelah mendapat kesempatan ke depan untuk opsi ke-3, kontrak 3 bulan saya berubah menjadi 3 tahun kerja keras, 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 cenderung gagal tanpa refactoring
  2. Refactor sebagai bagian dari pengembangan menunjukkan bahwa tes masih gagal.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.