10

Sebagai bagian dari tinjauan semua deskripsi pekerjaan, perusahaan saya telah memutuskan untuk memasukkan yang berikut ini sebagai output utama:

pengembangan situs web selesai tepat waktu, dalam spesifikasi dan bebas kesalahan

Mengingat bahwa spesifikasi secara teratur berubah, tidak ada proses kontrol perubahan formal dan lingkungannya, haruskah kita katakan, sedikit tidak dapat diprediksi, seberapa realistis dan masuk akal KPI ini?

terminology

— Phil.Wheeler
sumber

20

Sama sekali tidak realistis. Itu mungkin ditulis oleh seseorang yang bekerja dengan terlalu banyak pengembang yang buruk. Tapi itu juga bisa menjadi kesalahan manajemen yang buruk. Tidak cukup informasi yang diberikan.

— Mark Canlas

11

Pengembang yang datang dengan "menulis kode bebas kesalahan" pada resume mereka akan cukup menggelikan untuk mencocokkan posisi.

— P.Brian.Mackey

12

Satu-satunya kode yang dapat dibuktikan tidak memiliki bug dan mencapai tujuannya adalah basis kode kosong yang mengklaim tidak melakukan apa-apa.

— unholysampler

8

pfft ... sepertinya klausul kambing hitam untuk dapat dengan mudah orang. "Maaf, kamu tidak hidup sesuai dengan perjanjian kerja kamu ... kami akan memecatmu tanpa pemberitahuan atau sebab tambahan. Tootles."

— Steven Evers

5

Tentu saja itu bebas dari kesalahan. Kompiler mengatakan: 0 kesalahan, 0 peringatan. Itu sepenuhnya memenuhi persyaratan pekerjaan :-)

— Ferruccio

21

"Bebas Kesalahan" terlalu subjektif . "Permintaan fitur yang tidak terpenuhi" dari satu orang adalah "Kesalahan" dari orang lain. Sesuatu seperti "Harus secara substansial memenuhi spesifikasi desain" akan lebih tepat. Saya tidak pernah benar-benar melihat apa yang Anda gambarkan dalam deskripsi pekerjaan. Saya sudah melihatnya untuk pekerjaan kontrak , tetapi tidak untuk karyawan.

— GrandmasterB
sumber

9

Saya akan mengambil posisi berlawanan dengan sebagian besar jawaban dan mengatakan itu benar-benar masuk akal dan realistis.

Apakah semua pengembangan akan selesai tepat waktu? Tentu saja tidak, tidak selalu.

Apakah semua pengembangan akan diselesaikan dalam spesifikasi? Anda ingin berharap demikian, tetapi kadang-kadang itu tidak mungkin dan Anda harus menandai penyimpangan dari spesifikasi yang mustahil atau kontradiktif sendiri.

Dan apakah semua pengembangan akan bebas dari kesalahan? Tidak pernah .

Tapi itulah gunanya KPI. Ini adalah sesuatu yang dapat diukur dan dimana Anda dapat melacak kinerja dan kemajuan.

Jika spesifikasi berubah secara teratur, tidak ada proses kontrol perubahan formal dan lingkungan tidak dapat diprediksi, maka akan menjadi tantangan untuk menjaga angka ini dekat dengan "bebas dari kesalahan". Tapi tantangan itu adalah pekerjaan Anda , dan itu pekerjaan yang mudah-mudahan Anda lakukan dengan sangat baik - dan bahkan lebih baik tahun depan, saat Anda lebih banyak berlatih mengelola kekacauan khusus perusahaan Anda sendiri.

Pertanyaan balasan: KPI apa yang akan Anda usulkan untuk seorang programmer? Itu yang sulit. Banyak hal yang kita lakukan sulit untuk diukur.

— Carson63000
sumber

4

Basis kode dengan ukuran signifikan apa pun praktis tidak dapat dijamin sebagai "bebas kesalahan", karena mungkin ada kesalahan yang belum Anda temukan. Juga, apa kesalahannya? Bug? Bagaimana ini diukur?

— philosodad

1

@ philosodad - itu maksud saya. Itu tidak akan bebas dari kesalahan . Tetapi jika tahun ini x kesalahan ditemukan dalam kode yang Anda tulis, dan tahun berikutnya x-4 adalah, Anda telah meningkatkan KPI Anda. Seperti apa kesalahan itu, itu benar-benar masalah bagi organisasi Anda, dan tidak diragukan lagi salah satu yang akan menyebabkan beberapa argumen adalah "kesalahan" vs. "persyaratan tidak berdokumen" vs "persyaratan yang diubah" vs "perbedaan pendapat".

— Carson63000

3

@ Carson63000: tapi itu maksud saya! KPI yang dijamin menimbulkan beberapa argumen, mengarah pada pertikaian yang tak terhindarkan di antara para pihak, dan secara samar mendefinisikan metrik kunci, paling tidak, bermasalah. Untuk mengambil contoh Anda, jika "kesalahan" adalah ukuran subyektif, dapat diprediksi bahwa manajer akan menetapkan kesalahan ke bawah untuk membuat diri mereka terlihat lebih baik, sehingga semua orang akan mengurangi tingkat kesalahan untuk kinerja yang sama persis. Tetapi manajer baru mungkin mendefinisikannya, dan kemudian turun, untuk menunjukkan bagaimana mereka "meningkatkan" output yang persis sama.

— philosodad

3

Akan lebih baik untuk memiliki target tanpa kesalahan kritis (define critical). Atau memiliki tingkat kesalahan yang meningkat. Dan lebih baik lagi, hal ini harus menjadi target penilaian kinerja tahunan, bukan bagian dari deskripsi pekerjaan.

— cepat,

3

KPI melibatkan target yang tidak hanya tidak bisa dipenuhi tetapi juga bisa dilampaui. Anda menggunakannya untuk mengukur apakah Anda melakukan lebih buruk atau lebih baik dari target KPI. Saya tidak melihat bagaimana "bebas kesalahan" dapat dilampaui. Oleh karena itu, bahkan jika dimaksudkan sebagai KPI itu cacat. KPI yang lebih baik adalah dengan mengukur jumlah kesalahan, laporan pengujian yang dikirimkan terhadap kode yang Anda tulis yang menghasilkan perubahan kode aktual, dll.

— Marjan Venema

4

Jika itu adalah deskripsi pekerjaan, maka saya tidak akan terlalu khawatir tentang hal itu karena bekerja menuju kode bebas kesalahan adalah bagian dari pekerjaan khas programmer (bahkan jika kita tidak pernah dapat mencapainya).

Namun, sebagai KPI terlalu jauh jangkauannya, tetapi jangan salahkan orang yang menyarankannya jika mereka bukan programmer. Cukup jelaskan bahwa pernyataan itu menetapkan tujuan yang mungkin tidak diinginkan untuk organisasi. Artinya, "bebas kesalahan" adalah standar yang sangat tinggi untuk perangkat lunak yang akan membutuhkan banyak uang untuk benar-benar dikirimkan. Jelaskan bahwa proyek perangkat lunak yang dikelola dengan baik membutuhkan keputusan yang harus dibuat tentang apakah setiap cacat layak menghabiskan waktu pengembang yang berharga.

Berikut adalah contoh yang membuat intinya dengan baik.
Seorang programmer menemukan bahwa perangkat lunak kami memiliki bug "tahun 3000" dan akan berhenti berfungsi setelah 31 Desember 1999. Diperlukan 6-8 bulan untuk menyelesaikan masalah. Berdasarkan KPI didorong untuk mengambil proyek ini meskipun tidak memiliki nilai nyata bagi perusahaan.

Oke, jadi contoh itu agak ekstrem, tetapi dalam proyek perangkat lunak apa pun akan ada puluhan cacat kecil yang ditemukan yang juga tidak menghasilkan ROI yang diperlukan untuk memperbaikinya. Jika KPI dimaksudkan untuk menyiratkan bahwa programmer tidak pernah memperkenalkan cacat pada awalnya, apakah masuk akal bagi setiap karyawan untuk berpegang pada standar tidak pernah membuat kesalahan dalam kinerja pekerjaan mereka?

— JohnFx
sumber

Tampaknya tidak mungkin bahwa Anda memiliki KPI yang mencakup "memperbaiki kerusakan yang telah dianggap oleh manajemen tidak menjadi masalah, dan tidak perlu diperbaiki."

— Carson63000

@Carson - tidak di beberapa perusahaan besar yang saya kenal. Tujuan konyol adalah bagian dari cara mereka melakukan bisnis.

— cepat_now

3

Tidak

Bukan saja itu tidak tepat, itu menggelikan

Pengujian hanya dapat membuktikan adanya kesalahan, bukan ketidakhadirannya, sehingga setiap program yang ditulis dalam perjanjian ini harus menyertakan bukti ketelitian yang benar ... dan cakupan pengujian 100%

"Waspadalah terhadap bug dalam kode di atas; Saya hanya membuktikannya benar, tidak mencobanya." - D. Knuth

— Steven A. Lowe
sumber

KPI adalah ukuran keberhasilan dan kemajuan menuju tujuan. Mereka bukan beralih biner "kode bebas kesalahan = sukses, satu kesalahan tunggal = gagal, Anda dipecat!"

— Carson63000

@Carson: "bebas kesalahan" bukan KPI, itu fantasi.

— Steven A. Lowe

1

Bagi saya terdengar seperti menjahit. Masukkan sesuatu yang konyol di JD maka kapan saja diperlukan alasan orang itu bisa dipecat karena mereka tidak melakukan seperti yang dibutuhkan JD.

— cepat_now

3

Tentu saja adalah tugas setiap programmer, dan tanggung jawab, untuk menulis kode yang bebas kesalahan. Itu harapan yang masuk akal. Bagaimana Anda bisa menjadi programmer profesional jika Anda merilis kode yang tidak berfungsi? Bagaimana Anda dapat menganggap diri Anda sebagai programmer profesional jika Anda merilis kode yang tidak Anda ketahui berfungsi?

Jika Anda menyewa seorang pelukis, Anda berharap dia melakukan pekerjaannya dengan baik. Anda berharap hasil karyanya bebas kesalahan. Jika ada kesalahan, Anda berharap dia bertanggung jawab atas kesalahan itu dan memperbaikinya secara gratis. Terlebih lagi, jika kesalahan itu membuat Anda kehilangan uang, Anda berharap dia akan mengembalikan uang Anda. Mengapa Anda memiliki harapan ini? Karena pelukisnya adalah seorang profesional.

Programmer suka menyalahkan orang lain atas kesalahan mereka. "Program saya memiliki bug karena persyaratan, atau karena jadwal, atau karena Bulan ada di rumah ke-8" Tapi sebenarnya tidak ada orang lain yang bisa disalahkan. Jika program Anda memiliki kesalahan, Anda taruh di sana.

Profesi kita tidak akan pernah menjadi profesi sampai programmer menyadari bahwa tanggung jawab berhenti pada mereka. Bahwa mereka bertanggung jawab atas kualitas program mereka.

Apakah Anda tahu mengapa perusahaan membuat departemen QA Perangkat Lunak? Karena programmer tidak melakukan pekerjaannya! Programmer mengeluarkan banyak omong kosong sehingga perusahaan harus membentuk departemen baru untuk memeriksa mereka.

Berapa lama daftar bug? Profesional untuk memiliki ribuan bug di database bug? Jelas bukan. Itu adalah cerminan dari perilaku buruk, disiplin yang buruk, dan, sejujurnya, aib.

Kami tidak akan pernah menjadi profesi sampai kami menyadari bahwa itu adalah tugas kami untuk memastikan bahwa QA tidak menemukan apa pun.

— Paman Bob.
sumber

+1, tapi saya ingin menganggap bebas kesalahan sebagai tujuan pribadi daripada kenyataan. Kita semua harus melakukannya, tetapi kecuali diberikan sumber daya tak berujung kami tidak akan sampai di sana, setidaknya tidak diberikan bagaimana kami mengembangkan perangkat lunak sekarang.

— rjnilsson

Saya sangat setuju dengan sentimen Paman Bob. Ini adalah masalah profesionalisme.

— Johnsyweb

1

Posisi ini sedikit rumit oleh kenyataan bahwa manajemen saya sangat jelas bahwa mereka lebih suka saya memberi mereka perangkat lunak kereta sekarang, daripada perangkat lunak yang benar nanti. Saya tidak berpikir saya sendirian dalam situasi ini.

— Tom Anderson

3

Sayangnya ini hanya terdengar seperti cara bagi mereka untuk "menutupi semua pangkalan", dan jelas tidak direkomendasikan dan mungkin hanya menimbulkan kekecewaan pada pengembang.

Namun demikian, ini benar-benar hanya penting setelah Anda melihat apa yang mereka lakukan dengan teks tersebut selama periode peninjauan. Jadi jangan bereaksi terlalu cepat - mungkin masih ada kewarasan di ujung terowongan.

— Stephen Bailey
sumber

Mengingat lingkungan kerja saya saat ini, saya akan sangat curiga bagaimana mereka menerapkan kata-kata itu.

— Phil.Wheeler

2

"Bebas kesalahan" seperti "sempurna?" Seperti dalam "yang ditulis oleh Tuhan dan para malaikat, bukan manusia?" (kita berbicara di sini tentang kesalahan program-logika dan mungkin hardware-logika)

Saya tidak bisa mengatakan dengan jujur tentang satu baris kode pun tanpa kesalahan. Itu karena kita manusia, yah, kita tidak dapat membuktikan tidak ada hipotesis negatif!

Yang terbaik yang bisa saya katakan adalah bahwa probabilitas kesalahan adalah angka antara 0 dan 1. Saya mencapai angka itu dengan prinsip pengembangan dan pengujian perangkat lunak yang baik atau kurang dipahami dan dipahami dengan baik; oleh hitungan garis sumber perangkat lunak yang dimaksud; dengan pemahaman tentang seberapa baik atau buruknya kandidat, anjing malang, menerapkan prinsip-prinsip tersebut dalam menghasilkan garis-garis kode; dan lainnya.

Dan saya bisa mengungkapkan bahwa pemahaman hanya sebagai probabilitas. Jadi istilah "bebas kesalahan logika" berarti hampir tidak ada artinya.

Jika saya melihat iklan untuk insinyur perangkat lunak yang menghasilkan kode "bebas kesalahan", saya akan langsung mendaftar atau langsung kabur: perusahaan belum memikirkan bagaimana mengembangkan, menguji, dan memberikan perangkat lunaknya . Jadi itu akan menjadi peluang besar atau mimpi buruk tanpa akhir.

Dari perangkat lunak apa pun, saya dapat dengan mudah - dan harus - mengatakan saya mengharapkan kode yang tidak memiliki kesalahan yang berada di luar hal -hal yang sial, keruh, dan logis: kode yang menyusun dan menghubungkan tanpa kesalahan atau peringatan; itu adalah "html valid" atau "css valid"; JavaScript (katakanlah) yang tidak menghasilkan pesan kesalahan atau kesalahan browser yang tidak dapat dijelaskan. Bagian itu dapat saya ukur dengan lugas dan beri tanda hitam putih pada grafik.

Bagian itu semudah pie. Siapa saja bisa melakukan itu .

Hai, semoga sukses dalam pencarian Anda :-)

— Pete Wilson
sumber

1

Apakah saya bodoh, atau apakah "kesalahan" tidak berarti "pesan kompilator fatal sebesar kode yang tidak dapat dikompilasi"?

Menurut definisi itu, ini adalah persyaratan yang sangat masuk akal ...

— Chris Browne
sumber

1

Benar. Memiliki teks yang tidak selaras pada footer halaman mungkin merupakan kesalahan tetapi tentu saja tidak berada dalam kelas kesalahan yang sama dengan sesuatu yang mencegah halaman gagal memuat dan meludah kesalahan runtime kembali ke pengguna.

— FrustratedWithFormsDesigner

Dalam pengembangan web, "kesalahan" bisa berarti banyak hal. Menampilkan harga yang salah untuk semua produk Anda dapat dianggap sebagai kesalahan besar, tetapi itu tidak serta merta mencegah sesuatu berjalan, dan mungkin tidak melaporkan masalah apa pun di log server.

— Simon B

Dalam empat tahun sejak menulis komentar ini, saya telah melakukan lebih banyak pengembangan web dan sangat setuju - meskipun tidak biasa, saya akan mendukung jawaban saya dari 4 tahun yang lalu dan mengatakan bahwa intinya saya mencoba untuk buat adalah bahwa definisi "kesalahan" adalah sewenang-wenang, dan untuk (sangat) memilih definisi itu adalah persyaratan yang wajar.

— Chris Browne

Apakah pantas dalam deskripsi pekerjaan pengembang untuk memiliki "bebas kesalahan" sebagai output utama? [Tutup]

Tidak