Saya membuat poin cerita 4-5x lebih banyak daripada rata-rata, tetapi menghasilkan bug di setengah tingkat. Grafik mengatakan itu 2x bug lebih banyak, bagaimana menghadapinya?

Jadi secara umum diterima bahwa programmer tingkat atas dapat menghasilkan urutan kode lebih besar / lebih baik daripada rekan-rekan mereka yang lebih rata-rata.

Ini juga diterima secara umum bahwa tingkat kesalahan yang dibuat dalam kode relatif konstan untuk programmer.

Sebaliknya, itu cenderung dipengaruhi oleh proses yang digunakan saat menulis kode dan setelah kode ditulis . (Seperti yang saya pahami) Manusia cenderung membuat kesalahan dengan laju yang cukup konstan - programmer yang lebih baik hanya memperhatikan lebih banyak dari mereka dan lebih cepat memperbaikinya.

• Perhatikan bahwa kedua pernyataan di atas berasal dari Kode Lengkap oleh Steve McConnell - jadi ini bukan masalah perbedaan perspektif.

Jadi saya mulai melihat ini baru-baru ini di kode saya. Saya dapat menghitung sekitar 4-5x jumlah kode sebanyak rekan saya (diukur dengan poin cerita yang diperkirakan oleh tim), dengan kualitas yang lebih tinggi (berdasarkan metrik kinerja dan jumlah perubahan yang dilakukan setelah check-in). Tapi saya masih melakukan kesalahan. Di antara pengujian unit yang lebih baik, pemahaman yang lebih baik tentang apa yang kode lakukan, dan mata yang lebih baik untuk masalah ketika melakukan tinjauan kode saya tidak menghasilkan 4-5x jumlah bug.

Tapi saya masih menghasilkan bug dua kali lebih banyak yang ditemukan oleh QA dibandingkan pengembang lain di tim saya. Seperti yang Anda bayangkan, ini menyebabkan beberapa masalah dengan orang-orang non-teknis melakukan pengukuran metrik (baca: bos saya).

Saya sudah mencoba menunjukkan bahwa saya menghasilkan bug pada tingkat setengah dari rekan-rekan saya (dan memperbaikinya dua kali lebih banyak), tapi itu sulit dijual ketika ada grafik yang mengatakan saya menghasilkan bug dua kali lebih banyak.

Jadi, bagaimana menghadapi kenyataan bahwa peningkatan produktivitas akan menyebabkan peningkatan jumlah bug?

Saya pikir Anda mencampur keprihatinan Anda. Dan tidak ada pada Anda sisi yang Anda butuhkan untuk perubahan.

Produktivitas adalah petunjuk seberapa cepat sebuah proyek akan selesai. Manajer proyek dan semua orang ingin tahu kapan proyek akan dikirimkan. Produktivitas yang lebih tinggi atau lebih cepat berarti kita akan melihat proyek lebih cepat.

Tingkat bug tidak terkait dengan produktivitas tetapi lebih ke ukuran proyek. Misalnya, Anda mungkin memiliki Nbug per Ybaris kode. Tidak ada dalam metrik yang mengatakan (atau peduli!) Seberapa cepat baris kode itu ditulis.

Untuk menyatukan itu, jika Anda memiliki produktivitas yang lebih tinggi, ya, Anda akan "melihat" bug yang ditulis lebih cepat. Tapi Anda tetap akan memiliki jumlah bug itu karena itu terkait dengan ukuran proyek.

Jika ada, produktivitas yang lebih tinggi berarti Anda akan memiliki lebih banyak waktu di akhir proyek untuk memburu bug itu atau pengembang akan lebih cepat dalam menemukan bug yang mereka buat. ¹

Untuk mengatasi aspek yang lebih pribadi dari pertanyaan Anda.

Jika atasan Anda hanya memperhatikan jumlah bug yang Anda hasilkan dibandingkan dengan tingkat bug yang Anda hasilkan, sesi edukasi akan dilakukan. Jumlah bug yang dibuat tidak ada artinya tanpa tingkat dukungan.

Untuk mengambil contoh itu secara ekstrem, beri tahu atasan Anda, saya ingin menggandakan gaji Anda. Mengapa? Saya sama sekali tidak membuat bug pada proyek Anda dan karenanya saya adalah programmer yang jauh lebih unggul daripada Anda. Apa? Dia akan memiliki masalah yang saya belum menghasilkan satu baris kode untuk menguntungkan proyek Anda? Ah. Sekarang kami memiliki pemahaman tentang mengapa tingkat itu penting.

Sepertinya tim Anda memiliki metrik untuk mengevaluasi bug per poin cerita. Jika tidak ada yang lain, ini lebih baik daripada diukur dengan jumlah bug yang dibuat. Pengembang terbaik Anda harus membuat lebih banyak bug karena mereka menulis lebih banyak kode. Mintalah bos Anda membuang grafik itu atau setidaknya melemparkan seri lain di belakangnya yang menunjukkan berapa banyak poin cerita (atau nilai bisnis apa pun yang Anda ukur) di samping jumlah bug. Grafik itu akan menceritakan kisah yang lebih akurat.

¹ _{Komentar khusus ini telah menarik lebih banyak perhatian daripada yang dimaksudkan. Jadi mari kita menjadi agak jagoan (kejutan, saya tahu) dan mengatur ulang fokus kami pada pertanyaan ini.}

_{Akar dari pertanyaan ini adalah tentang manajer yang melihat hal-hal yang salah. Mereka melihat total bug mentah ketika mereka harus melihat tingkat generasi versus jumlah tugas yang diselesaikan. Jangan terobsesi mengukur "garis kode" atau poin cerita atau kompleksitas atau apa pun. Itu bukan pertanyaan yang ada dan kekhawatiran itu mengalihkan kita dari pertanyaan yang lebih penting.}

_{Seperti yang tercantum dalam tautan oleh OP, Anda dapat memprediksi sejumlah bug dalam proyek murni berdasarkan ukuran proyek saja. Ya, Anda dapat mengurangi jumlah bug ini melalui berbagai pengembangan dan teknik pengujian. Sekali lagi, itu bukan inti dari pertanyaan ini. Untuk memahami pertanyaan ini, kita harus menerima bahwa untuk proyek ukuran dan metodologi pengembangan yang diberikan, kita akan melihat sejumlah bug setelah pengembangan "selesai."}

_{Jadi mari kita kembali ke komentar ini yang sedikit disalahpahami. Jika Anda menetapkan tugas dengan ukuran yang sebanding untuk dua pengembang, pengembang dengan tingkat produktivitas yang lebih tinggi akan menyelesaikan tugas mereka sebelum yang lain. Karena itu, pengembang yang lebih produktif akan memiliki lebih banyak waktu di akhir jendela pengembangan. "Waktu tambahan" itu (dibandingkan dengan pengembang lain) dapat digunakan untuk tugas-tugas lain seperti mengerjakan cacat yang akan meresap melalui proses pengembangan standar.}

_{Kami harus mengambil OP pada kata mereka bahwa mereka lebih produktif daripada pengembang lain. Tidak ada satu pun dari klaim tersebut yang menyiratkan bahwa OP atau pengembang lain yang lebih produktif menjadi tak berguna dalam pekerjaan mereka. Menunjukkan bahwa akan ada lebih sedikit bug jika mereka menghabiskan lebih banyak waktu pada fitur atau menyarankan bahwa debugging bukan bagian dari waktu pengembangan ini melewatkan apa yang diminta. Beberapa pengembang lebih cepat daripada yang lain dan menghasilkan pekerjaan yang kualitasnya sebanding atau lebih baik. Sekali lagi, lihat tautan yang dijabarkan OP dalam pertanyaan mereka.}

Habiskan sebagian waktu ekstra untuk membersihkan, memoles, dan menguji kode Anda. Masih akan ada kesalahan, tetapi akan ada lebih sedikit. Itu butuh waktu. Tingkat output kode Anda akan turun, tetapi output kode bebas bug Anda akan meningkat, dan itu akan menghasilkan produktivitas yang lebih baik. Karena bug itu mahal.

Bisakah Anda menyimpan kode di cabang atau lingkungan pengujian sampai Anda menendang dan menangkap lebih banyak bug? Bug di cabang umumnya menyebabkan lebih sedikit gelombang daripada bug dalam kode produksi.

Tapi saya tidak benar-benar menggali pernyataan Anda yang mengarah ke pertanyaan Anda. Dan mungkin bos Anda juga tidak.

Saya tidak berpikir bahwa setiap pembuat kode menghasilkan tingkat kesalahan yang sama. Tautan kedua Anda sebenarnya sepenuhnya di luar topik karena membandingkan berbagai bahasa, bukan tingkat keterampilan pembuat kode yang berbeda. Kode lengkap menyebutkan beberapa pengukuran sampel besar yang melihat proses daripada keterampilan coders. Dan ketika mereka mengatakan bahwa pembuat kode tingkat atas menghasilkan lebih banyak kode yang lebih baik, sebagian itu berarti memiliki lebih sedikit bug. Tergantung pada aplikasi. Jadi, ya, saya pikir ini masalah perspektif yang berbeda.

Pada akhirnya, jika bos menginginkan kode pembersih, berikan kode pembersih kepadanya.

Aku akan mengambil risiko dan menjadi penasihat iblis. Itu bukan untuk mengatakan saya tidak bersimpati dengan keadaan Anda, tetapi, baik, simpati saya tidak akan membantu Anda. Jadi izinkan saya untuk menambah perspektif Philip :

Bos Anda peduli dengan kualitas produk, sebagian karena nama dan reputasinya akan terikat padanya. Bagian dari kualitas adalah jumlah bug yang dirasakan . Jika Anda menjual latihan yang luar biasa yang melatih empat kali lebih cepat daripada latihan yang bersaing, tetapi juga gagal dua kali lebih sering, Anda akan memiliki reputasi yang buruk. Meskipun diperdebatkan bahwa latihan berkinerja lebih baik, orang-orang terbiasa dengan kecepatan, tetapi mereka akan mengingat kerusakannya.

Jika diperhatikan, sebagian besar bug jelas dapat dicegah. Andai saja Anda sedikit lebih berhati-hati, bos Anda akan merasa, Anda bisa menghindari masalah ini dan melakukan pembersihan yang perlu. Dari sudut pandangnya, itu hal sepele, hal yang masuk akal untuk ditanyakan, dan setiap pertengkaran yang Anda lakukan tentang keduanya tidak akan berhasil dan akan membuat Anda terlihat buruk.

Dia tidak dapat mengukur produktivitas superior Anda. Anda mengklaim produktivitas yang lebih tinggi berdasarkan metrik yang dapat diverifikasi, jadi bagaimana perasaan rekan kerja Anda tentang hal itu? Apakah mereka setuju, mungkin dengan enggan, bahwa Anda adalah programmer yang lebih produktif, atau apakah Anda sendirian menurut pendapat Anda? Anda akan membuat poin yang lebih kuat jika Anda memiliki orang lain untuk mendukung pernyataan Anda.

Itu untuk perspektif. Sekarang, bagaimana Anda bisa 'memperbaiki' situasi yang membuat Anda frustrasi ini?

Lakukan sedikit memperlambat. Sebutkan secara eksplisit kepada siapa pun yang mendistribusikan tugas yang akan Anda coba untuk menurunkan tingkat bug (*), sehingga mereka tidak terkejut dengan asupan Anda yang lebih rendah. Jika ada, memperlambat akan mengurangi jumlah bug yang ditugaskan kepada Anda karena kurangnya pasokan.

_{(*) Ada perbedaan antara, di satu sisi, mengakui bahwa ada yang bug nama Anda dan bahwa Anda akan mencoba untuk mengurangi jumlah itu dan, di sisi lain, mengakui bahwa Anda memiliki terlalu banyak bug nama Anda dan harus mengambil tindakan.}

Jangan mencoba meyakinkan bos Anda, karena itu tidak akan berhasil. Sekali lagi, itu tidak berarti Anda harus mengakui maksud Anda; Anda dapat menunjukkan titik tandingan dan memegang pendapat Anda tanpa mengabaikan kekhawatirannya. Karena jika Anda benar-benar memperdebatkan hal itu dan tidak dapat secara memuaskan membuktikan produktivitas superior Anda (dan bahkan jika Anda bisa), Anda akan berisiko menghina kolega Anda, atau tampak menolak mereka. Anda tidak ingin menjadi pria itu .

Dengan asumsi Anda akan menghasilkan "jumlah" kode yang sama seperti kolega Anda dalam 20% dari waktu mereka, Anda dapat menghabiskan 4 kali lebih banyak untuk benar-benar men-debug kode dan membuatnya sempurna, yang akan mengurangi tingkat bug Anda lebih banyak lagi. Maka Anda bisa menyebut diri Anda seorang programmer yang baik.

Pertanyaan terbesar adalah mengapa Anda mengkode 5 kali lebih banyak daripada yang lain alih-alih membidik kualitas. Apakah ini sesuatu yang ego Anda perintahkan atau atasan Anda memaksa Anda?

Anda juga perlu mempertimbangkan biaya untuk memperbaiki bug. Ketika Anda menemukannya lebih awal Anda mungkin masih "dalam" kode cukup untuk memperbaikinya dengan cepat. Jika itu muncul hanya setelah satu bulan pembangunan, mungkin sulit untuk menemukan atau bahkan memaksa Anda untuk mengubah bagian besar dari kode yang sudah diprogram.

Anda tampaknya memiliki ketrampilan untuk menghasilkan kode, dan Anda dapat membuatnya luar biasa jika Anda lebih mengutamakan kualitas daripada kecepatan. Cobalah sebentar, tebakan saya Anda akan menyukainya.

Masalah selanjutnya adalah mendapatkan pengakuan (bicara uang) untuk kinerja Anda yang lebih baik. Bicaralah dengan bos Anda dan tanyakan padanya bagaimana untuk melanjutkan, itu adalah perusahaan dan uangnya, dan jika dia ingin Anda menghasilkan lebih sedikit bug, ia juga harus memutuskan bagaimana hal itu terjadi.

Pengembang bisa cerdas, bahkan jenius, dengan bakat untuk memahami dan mengkode solo, tanpa menjadi pengembang yang BAIK. Pengembang yang baik menciptakan karya berkualitas, dan menjadikan keseluruhan proyek lebih baik.

Saya tidak mengatakan ini adalah Anda, tetapi salah satu programmer yang paling membuat frustrasi yang pernah bekerja dengan saya menulis lebih banyak kode daripada siapa pun di tim, dan kami memiliki orang-orang baik di tim. Kami melacak komitmen dengan perangkat lunak peringkat, jadi itu hampir merupakan kompetisi bagi sebagian orang. Dia mengeluarkan banyak kode, meninggalkan dokumentasi NOL, hutan yang tidak bisa ditembus, dan benar-benar membuat beberapa kode saya sendiri sulit untuk saya pahami (saya bisa melakukannya sendiri, terima kasih banyak!). Akhirnya dia hampir menggagalkan proyek, karena dia menjadi pertunjukan satu orang. Orang tidak bisa mengikutinya. Kami tidak selaras sebagai sebuah tim. Kami sebenarnya menulis ulang beberapa fitur-fiturnya bertahun-tahun kemudian, hanya untuk mendapatkan kembali perawatannya.

Hal yang saya inginkan darinya adalah memperlambat, dan menghabiskan lebih banyak waktu: 1) Meningkatkan kualitas basis kode 2) Berkomunikasi dengan tim 3) Mengerjakan hal-hal yang membantu orang lain serta membantunya menyelesaikan fitur / cerita 4) Memperbaiki bug

Saya tidak setuju untuk mengukur produktivitas berdasarkan baris kode, tetapi ini adalah metrik kunci. Apakah penghitung kode Anda menyertakan komentar? Jika demikian, ada cara mudah untuk mempertahankan output baris Anda sambil mengurangi "rasio bug" Anda; cukup tingkatkan kualitas dan kuantitas komentar yang Anda tulis. Komentar jarang memiliki bug (meskipun mereka bisa) dan secara umum, kami tidak memiliki komentar berkualitas yang cukup. Saya tidak memaafkan inflasi kode, tetapi tindakan berkomentar seperti review kode mini, itu memaksa Anda berpikir, refactor, dan meningkat.

Mencoba untuk mencerahkan manajemen bukanlah hal yang baru. Ada klise lama, "Apakah Anda akan mempercayai saya atau mata bohong Anda?" Yang menjadi perhatian bos Anda adalah jumlah bug. Tidak ada jumlah rasionalisasi yang akan memberitahu mereka itu dapat diterima. Ini lebih dari dua kali berisiko. Selain itu, Anda bukan satu-satunya yang terpengaruh oleh jumlah bug Anda. QA memiliki dua kali pekerjaan yang berusaha mengidentifikasi bug Anda, sehingga manajemen ingin Anda mengurangi bug mereka.

Solusi terbaik adalah mengurangi jumlah bug yang Anda hasilkan , titik. Tidak hanya manajemen akan lebih bahagia, tetapi Anda juga akan lebih. Bukan? Karena saya cukup yakin sebanyak Anda menikmati membual Anda mengungguli rekan kerja Anda dengan faktor empat, Anda akan senang mengatakan Anda melakukannya dengan jumlah yang sama, atau bahkan lebih sedikit, bug daripada yang mereka lakukan.

Seperti yang Anda nyatakan, "... tingkat kesalahan yang dibuat dalam kode ... cenderung dipengaruhi oleh proses yang digunakan saat menulis kode dan setelah kode ditulis." Jika Anda ingin mengubah kecepatan Anda menghasilkan bug, Anda harus mengubah proses yang Anda gunakan untuk menulis kode.

Programmer menggunakan metode produksi untuk menghasilkan kode, seperti jalur perakitan menggunakan metode untuk menghasilkan beberapa objek yang diproduksi secara massal. Oke, praktik industri perangkat lunak lebih seperti pernak pernik dari cabang yang ditemukan di hutan. Tetapi karena kita memproduksi mesin, kita harus menggunakan ketelitian dan disiplin yang sama dengan yang digunakan untuk mesin kecepatan tinggi produksi massal.

Itu termasuk teknik yang sama yang digunakan dalam produksi massal untuk mengurangi tingkat cacat: analisis akar-penyebab untuk menentukan mengapa bug dibuat, dan mengubah prosesnya jadi tidak. Atau setidaknya Anda menangkapnya sebelum QA melakukannya.

1. Buat daftar bug Anda. Anda mungkin sudah mendapatkannya berkat QA guys. Mungkin dikategorikan juga. Jenis bug, tingkat keparahan, titik di mana bug disuntikkan ke dalam kode, dll.

2. Pilih kategori bug terbesar. Karena volume Anda sangat tinggi, Anda harus menargetkan kategori itu terlebih dahulu. Kategori lain termasuk yang paling mudah ditemukan, dan yang paling mudah dibuat.

3. Mengetahui di mana bug itu dimasukkan ke dalam kode, lihatlah untuk membuat perubahan pada fase itu (dan sebelumnya) yang mencegah bug itu terjadi, dan cara-cara untuk membuatnya lebih mudah ditangkap pada fase itu.

4. Pastikan untuk melihat non-pemrograman terkait yang terkait serta mereka dapat membuat perbedaan dalam kualitas pekerjaan Anda. Musik latar, interupsi, waktu makan, bekerja terlalu lama tanpa istirahat, lapar, dll.

Apa yang Anda temukan dapat membuat Anda lebih lambat. Di sisi lain, ini dapat membantu Anda menghasilkan lebih cepat karena Anda tidak perlu lagi mengerjakan ulang barang-barang yang sudah Anda masukkan. Seperti itu, kode empat kali lebih banyak tidak mendekati urutan besarnya lebih baik dari rekan kerja Anda, jadi mengubah proses Anda adalah cara yang paling pasti.

Ubah tujuan Anda dari menghasilkan kode terbanyak menjadi membantu perusahaan untuk paling maju.

Karena tampaknya Anda memiliki banyak kolega plus waktu ekstra yang tersedia, efek paling besar yang dapat Anda miliki pada pengiriman fitur dan perbaikan bug yang lebih cepat adalah membantu kolega Anda.

Bantu kolega Anda dengan

• menggunakan ulasan kode untuk meningkatkan kualitas kode dan pendidikan.
• menciptakan otomatisasi proses untuk membuat pekerjaan mereka lebih cepat dan kehidupan mereka lebih mudah.
• menulis tes yang lebih baik dengan mereka
• menyerang kode teknis untuk meningkatkan basis kode
• menjadi orang yang selalu siap membantu orang lain.
• alat menulis / meningkatkan yang membantu dengan produktivitas pengembang
• membuat kasus dengan manajemen untuk alat / peralatan / kondisi kerja yang lebih baik untuk rekan kerja Anda jika Anda memiliki kekuatan lebih.
• mempersiapkan dan memimpin sesi pendidikan tentang penulisan kode yang lebih baik.
• mempraktikkan kerendahan hati

Jadi, bagaimana menghadapi kenyataan bahwa peningkatan produktivitas akan menyebabkan peningkatan jumlah bug?

Atasan Anda adalah satu-satunya orang yang dapat menjawab ini dalam kasus Anda. Bicaralah dengannya, tunjukkan rasio Anda yang lebih baik dan biarkan dia memutuskan. Jika keputusannya tidak masuk akal, sekarang saatnya mencari perusahaan dengan cara berpikir Anda.

Sebagai seorang profesional Anda harus dapat bekerja dengan kondisi klien apa pun, pastikan mereka memahami konsekuensinya. Grafik bug / cerita yang bagus dapat membantu bos Anda memahami seberapa besar produktivitas Anda akan tenggelam jika Anda meluangkan waktu untuk menghasilkan lebih sedikit bug.

Anda juga perlu mempertimbangkan poin-poin ini:

• kompleksitas cerita, misalnya pembungkus pengambil / penyetel sederhana versus perhitungan statistik atau pemrograman waktu nyata atau bahkan statistik waktu nyata ...
• parahnya bug, apakah kesalahan ketik kecil pada bidang teks atau hasil perhitungan yang salah, program macet
• biaya untuk memperbaiki bug, baik jika Anda melakukannya sekarang, nanti atau jika orang lain harus memahami kode Anda karena Anda pergi

Situasinya adalah Anda bekerja empat kali lebih cepat dari rata-rata programmer, tetapi Anda membuat kesalahan dua kali lebih banyak dalam jumlah waktu tertentu. Sehubungan dengan jumlah pekerjaan yang Anda lakukan, Anda sebenarnya membuat SETENGAH kesalahan sebanyak "rata-rata."

Anda dapat mencoba menunjukkan rasio kesalahan rendah untuk bekerja, atau bahkan kesalahan untuk menyelesaikan produk (yang dapat Anda selesaikan dalam seperempat waktu normal). Kebanyakan bos akan menerimanya.

Ada beberapa bos yang tidak akan melakukannya karena mereka bekerja dengan pola pikir kesalahan "uang saku" per waktu. Maka Anda mungkin memperlambat laju pekerjaan Anda, melakukan DUA KALI sebanyak pekerjaan rata-rata dalam waktu tertentu, dan membuat kesalahan yang sama (atau lebih sedikit) karena Anda memiliki lebih banyak waktu untuk memeriksa pekerjaan Anda.

Jika atasan Anda ingin Anda meningkatkan kualitas pekerjaan Anda, maka tingkatkan kualitas pekerjaan Anda.

Anda harus membidik zero bug, tidak bertujuan untuk menghasilkan hanya dua kali lebih banyak dari programmer terbaik berikutnya.

Anda harus memberi tahu atasan Anda bahwa metrik yang digunakannya cukup cacat. Jika Anda melihat turnover oleh penjaga di NBA, Anda akan menemukan bahwa mereka cenderung memiliki angka yang lebih tinggi daripada ke depan. Tapi, itu karena mereka lebih banyak memegang bola. Jika penjaga yang tidak memulai memainkan 1/5 seperti penjaga awal dan memutar bola rata-rata 3 kali .vs. penjaga awal yang memutar bola lebih dari 7 kali per pertandingan - pada pandangan pertama mungkin terlihat seperti penjaga awal lebih buruk. Tetapi, jika Anda membagi jumlah turnover dengan jumlah menit yang dimainkan, maka jelas penjaga awal memiliki angka yang jauh lebih baik berdasarkan menit yang dimainkan.

Demikian juga, Anda memiliki angka yang jauh lebih baik jika jumlah bug dibagi dengan jumlah poin cerita yang diselesaikan. Jadi, itulah yang akan saya usulkan kepada manajer Anda. Ubah metrik menjadi jumlah bug yang dibagi dengan poin cerita yang diselesaikan, atau setidaknya tambahkan metrik untuk ini jika jumlah total bug per pengembang diperlukan. Tetapi, karena beberapa poin cerita jauh lebih sulit dan lebih kompleks daripada poin cerita lainnya, akan ada dan akan ada sedikit perbedaan dan ini perlu dipertimbangkan oleh manajer juga.

Apa yang saya pikir tidak harus Anda lakukan adalah memperlambat.

Mengukur nilai tambah

Berargumen bahwa yang benar-benar penting adalah nilai yang Anda tambahkan. Lalu pergi dan perkenalkan pengukuran kasar (manual) tentang itu:

• Perkirakan nilai fungsionalitas yang Anda hasilkan
• Kurangi gaji Anda
• Kurangi perkiraan biaya bug Anda (setidaknya biaya untuk memperbaikinya)
• Kurangi perkiraan biaya semua Utang Teknis lain yang Anda hasilkan

Sisanya adalah nilai tambah Anda. Demikian juga untuk semua orang.

Perkiraan ini sulit, tetapi bahkan perkiraan kasar pun bisa menjadi alasan. Dan proses semata-mata membahas perkiraan ini berguna untuk tim dan proyek.

Pemrogram top memiliki kecenderungan untuk menulis kode yang sangat teratur yang mudah didebug dan dipahami, mereka menggunakan alat yang tersedia (analisis statis, kesalahan kompiler, kode debug) secara maksimal. Selain itu, pemrogram top sudah belajar nilai pengujian unit melalui pengalaman kerasnya sendiri.

Jadi, sementara jumlah awal masalah per baris adalah sama, masalah diselesaikan lebih cepat.