Apakah "selama itu berhasil" adalah norma? [Tutup]


23

Lihat pertanyaan saya yang lebih baru: Apakah pemrograman sebagai profesi dalam perlombaan ke bawah?

Toko terakhir saya tidak memiliki proses. Agile pada dasarnya berarti mereka tidak memiliki rencana sama sekali tentang bagaimana mengembangkan atau mengelola proyek mereka. Itu berarti, "hei, ini pekerjaan yang berat. Lakukan dalam dua minggu. Kita cepat dan gesit."

Mereka merilis barang-barang yang mereka tahu memiliki masalah. Mereka tidak peduli bagaimana hal-hal ditulis. Tidak ada ulasan kode - meskipun ada beberapa pengembang. Mereka merilis perangkat lunak yang mereka tahu buggy.

Di pekerjaan saya sebelumnya, orang-orang memiliki sikap selama itu berhasil, tidak apa-apa. Ketika saya meminta penulisan ulang beberapa kode yang saya tulis saat kami sedang mengeksplorasi spec, mereka menolaknya. Saya ingin menulis ulang kode karena kode diulangi di banyak tempat, tidak ada enkapsulasi dan butuh waktu lama bagi orang untuk mengubahnya.

Jadi pada dasarnya, kesan saya adalah ini: pemrograman bermuara pada hal berikut:

  1. Membaca beberapa buku tentang alat / teknologi terbaru
  2. Melempar kode bersama berdasarkan ini, menghindari penulisan kode individual karena perusahaan tidak ingin "mempertahankan kode kustom"
  3. Menampilkannya dan beralih ke hal berikutnya, "selama itu berhasil."

Saya selalu mengatakan pada diri sendiri bahwa pekerjaan berikutnya saya akan mendapatkan toko yang lebih baik. Itu tidak pernah terjadi. Jika ini dia, maka saya merasa mandek. Teknologi selalu berubah; jika satu-satunya pengembangan profesional di sini adalah membaca buku teknologi MS Press terbaru, lalu apa yang telah Anda bangun dalam 10 tahun tetapi pengetahuan yang dangkal dari berbagai teknologi? Saya khawatir tentang:

  1. Cara terbaik untuk memiliki standar profesional
  2. Bagaimana mengembangkan pengetahuan dan pengalaman yang berarti dalam situasi ini

3
Negara apa ini?

3
Inevitable referensi Dilbert: runningagile.files.wordpress.com/2007/11/...
nikie

5
<quote> Agile pada dasarnya berarti mereka tidak memiliki rencana sama sekali tentang cara mengembangkan atau mengelola proyek mereka </quote> Ini tidak tangkas. Ini bukan apa-apa.
Martin York

4
@ Martin York: Benar, tetapi beberapa tempat tampaknya menyebut diri mereka Agile ketika mereka tidak memiliki rencana atau spesifikasi. Ini seperti memainkan cello tanpa tahu di mana harus meletakkan jari-jari kiri pada senarnya, dan menyebutnya musik yang tidak resmi.
David Thornley

2
Saya pikir orang kehilangan titik pertanyaan. Maksud saya adalah dinamika yang saya jelaskan di sini tampaknya tidak benar-benar membutuhkan keterampilan atau menyebabkan pengembang membangun keterampilan. Tampaknya mengarah pada pengembangan tingkat pengetahuan yang dangkal yang tidak bertahan lama. Akuntan, pengacara, dll. Mengembangkan pengalaman yang membuat pelatihan mereka lebih berharga. Mengingat dinamika yang saya lihat di sini, saya tidak menjadi masalah bagi kita.
q303

Jawaban:


8

Anda secara tidak langsung menemukan apa yang saya pikir adalah aspek kunci untuk menjadi pengembang yang baik : mencapai keseimbangan antara " selama ini berhasil " dan kode yang dirancang dengan baik dan elegan.

Sama seperti dalam politik, jauh lebih mudah untuk mempertaruhkan posisi Anda di salah satu ujung spektrum dibandingkan mengambil posisi yang bernuansa di tengah. Mayoritas pengembang yang saya temui jatuh ke dalam salah satu dari dua kategori: pengodean koboi dan astronot arsitektur. Saya mencoba untuk mencapai keseimbangan di antara keduanya. Tidak semudah kedengarannya.

Untuk lebih langsung menjawab pertanyaan Anda, ya, saya pikir "selama ini berhasil" sering menjadi norma. Tetapi lihatlah dengan cara lain: Anda berada dalam posisi yang sangat baik untuk mendidik kolega Anda dan mencoba memperkenalkan beberapa praktik yang lebih baik. Tapi jangan terlalu ekstrem, dan ingat mengapa kita semua melakukan ini: untuk menyelesaikan masalah pelanggan kita.


2
+1 Terutama, untuk:remember why we're all doing this: to solve our customer's problems.
George Marian

21

>> Di pekerjaan saya sebelumnya, orang-orang memiliki sikap selama itu berhasil, tidak apa-apa.

Mungkin saya minoritas di sini tetapi saya memiliki sikap yang sama dan saya sangat percaya bahwa untuk menulis ulang sesuatu harus ada bukti yang jelas mengapa kita membutuhkan ini. Dan saya tidak bermaksud sesuatu seperti "uf, saya tidak suka bagaimana itu dikodekan" - setiap pengembang memiliki preferensi tentang kode. Seharusnya ada beberapa masalah dengan bagian yang ingin kita tulis ulang:

  • Masalah kinerja
  • Ada lebih banyak bug yang ditemukan daripada di bagian lain dari sistem
  • Pengembang menghabiskan lebih banyak waktu ketika mereka mengerjakan bagian ini
  • dll.

7
+1I strongly believe that to rewrite something there should be clear evidence why do we need this
George Marian

3
+1. Sebagian besar programmer tampaknya sangat bersemangat tentang kode , keindahan dan kemurnian dll. Mereka tidak menyadari kode sebenarnya hanya artefak dari hal yang seharusnya mereka kembangkan. Pada akhirnya, yang penting adalah bahwa itu berfungsi. Itulah yang diperhatikan oleh pelanggan Anda yang membayar.
Joonas Pulakka

9
Saya tidak punya masalah dengan jawaban Anda, tetapi sikap ini sering digunakan oleh manajemen untuk tidak setuju dengan semua alasan sebenarnya yang baik untuk menulis ulang kode - "Itu bukan alasan yang sebenarnya" dan mereka melanjutkan.
Nicole

4
@Michael: Refactoring sangat penting. Begitu juga kodenya bekerja. Demikian juga dengan cepat, karena pesaing Anda akan menang. Juga sangat penting untuk menyelesaikannya dengan sumber daya yang terbatas karena ada sedikit uang dan banyak hal lain yang harus dilakukan. Ada beberapa hal yang sangat penting, dan bisnis adalah tentang menyeimbangkan keduanya. Bukan tugas yang mudah tapi yang sukses, seperti Google, tampaknya selalu bersandar kepada "mendapatkan sesuatu dengan cepat, polish nanti" sikap.
Joonas Pulakka

3
@Joonas Pulakka: Itu sepenuhnya tergantung pada pasar. Untuk situs web, menjadi yang pertama sering kali lebih penting daripada memiliki produk terbaik, jadi itulah yang dilakukan Google dan lainnya. Di sisi lain, jika Anda mencoba untuk "mengeluarkan sesuatu dengan cepat, memolesnya nanti" dengan misalnya peralatan medis yang kritis, Anda mungkin tidak akan memiliki bisnis lama.
nikie

14

Agile tidak bertanggung jawab atas manusia yang memutuskan untuk merilis perangkat lunak kereta; manusia.

Yang mengatakan, Anda memberi banyak kepentingan untuk kualitas, dan itu bagus. Saya yakin Anda seorang perfeksionisme dan Anda peduli dengan nilai Anda sendiri jika Anda tidak mengejar teknologi terbaru.

Masalahnya adalah bahwa perfeksionisme mengarah pada prokrastinasi dan prokrastinasi menyebabkan mediokritas .

Itu sebabnya bisnis akan memprioritaskan hal-hal seperti waktu untuk memasarkan dan menggunakan gesit untuk memberikan nilai dengan cepat dan pada kecepatan yang dapat diprediksi.

Karena Anda tidak menggambarkan strategi bisnis perusahaan Anda, saya pikir Anda harus mulai dengan menanyakan hal itu kepada manajer Anda.

Dengan menjadi selaras pada tujuan dan rencana mereka (mereka mempekerjakan Anda untuk membantu mereka mencapainya), Anda akan berada dalam posisi yang lebih baik untuk memahami bagaimana Anda dapat berkontribusi pada mereka daripada berfokus pada tujuan Anda sendiri dan pribadi.

Saya yakin bahwa dengan mencoba understandnilai mereka, Anda akan dapat membagikan milik Anda, dan itu akan menjadi awal dari kolaborasi yang bermanfaat.

Dan jika Anda menemukan mereka tidak tahu apa yang mereka lakukan, satu-satunya pilihan Anda adalah berhenti .


2
Saya terutama menyukai baris ini:The problem is that perfectionism leads to procrastination and procrastination leads to mediocrity.
George Marian

1
Pierre seperti Yoda dari situs ini!
ozz

3

Itu semua tergantung pada apa yang Anda bangun. Jika Anda membuat sebuah microsite yang hanya akan online selama sebulan, dan Anda memiliki sembilan hari untuk membangunnya: maka ya, selama itu berhasil akan cukup.

Jika Anda menulis algoritma fly-by-wire untuk sistem FA-18, maka lebih baik dibuat sesempurna mungkin.

Jadi seperti halnya dengan sebagian besar jawaban teknologi ... itu tergantung.


2

Itu tergantung pada perusahaan. Namun, banyak perusahaan memiliki persaingan yang serius dan tekanan waktu. Itu salah satu alasan umum. Yang lain akan menjadi beban kerja yang besar, berpotensi tanpa staf yang cukup. (Ada beberapa alasan yang sangat bagus untuk kekurangan pegawai, yang tidak selalu merupakan kesalahan perusahaan.) Yang mengatakan, beberapa organisasi tidak dapat mengelola jalan keluar dari kantong kertas basah.

Saya pikir aturan 80/20 berlaku di sini. Pada dasarnya, Anda perlu memasang dengan 80% jelek dan bekerja dengan cara Anda menjadi 20%. Namun, sadari bahwa bahkan mereka harus melakukan pertukaran. Dalam bisnis, biasanya tidak masalah bahwa Anda benar. Itu penting bahwa Anda memilikinya sekarang.


2

jika satu-satunya pengembangan profesional di sini adalah membaca buku teknologi MS Press terbaru, lalu apa yang telah Anda bangun dalam 10 tahun tetapi pengetahuan yang dangkal dari berbagai teknologi?

Itu akan agak sial tetapi mungkin ada beberapa kegagalan spektakuler untuk dicatat dalam dekade itu. Saya telah melihat banyak tempat di mana saya dapat mengingat hal-hal yang agak spesifik yang saya sukai tentang bekerja di sana atau tidak menikmati dan dengan demikian akan mempertanyakan memiliki hal itu lagi di tempat kerja baru saya. Kadang-kadang mungkin ada praktik baru untuk dicoba seperti jika sebuah perusahaan mencoba untuk mengimplementasikan Scrum atau mengadopsi pendekatan Pengembangan yang Didorong oleh Tes, itu mungkin peluang tetapi tidak selalu melihat pengembangan profesional karena tidak dalam pengaturan ruang kelas formal.

Saya tahu berbagai tempat di mana "selama itu bekerja" adalah umum bersama dengan berbagai strategi pengkodean koboi. Dalam beberapa kali permulaan, saya telah melihat mentalitas seperti ini yang masuk akal jika perusahaan masih sangat muda sehingga mereka masih berusaha untuk menghilangkan ide tentang apa yang sebenarnya mereka coba lakukan. Di perusahaan lain saya telah bekerja, ada lebih banyak proses dan kedewasaan yang bisa sangat baik meskipun tidak selalu mudah untuk menemukan saya takut. Beberapa tempat memiliki beberapa proses yang harus saya lihat dan pergi, "Saya suka itu. Saya akan ingat itu untuk situasi kerja nanti," dan yang lain ke mana saya pergi, "Saya benar-benar tidak suka itu. Saya akan perhatikan untuk mencoba menghindari itu di masa depan. "


2

Saya bekerja di toko seperti ini untuk sementara waktu hanya pada titik di mana ia mengejar mereka. Ada dua atau tiga tahun aplikasi lama dengan bug yang diketahui bahwa mereka benar-benar tidak dapat memecahkan. Pikirkan loop panjang 4.000 garis dengan perhitungan berjalan untuk lebar dan ketinggian tata letak. Memperbaiki sepotong kode untuk memperbaiki masalah dalam satu contoh akan menghasilkan dua puluh masalah di tempat lain karena pengembang sebelumnya memiliki masalah serupa yang dibantu oleh band dengan sewenang-wenang menyesuaikan hasil perhitungan dengan angka ajaib. Kode tidak dapat digambarkan sebagai selain racun.

Saya akhirnya diberi proyek baru yang menurut atasan saya bisa menggunakan kode yang ada ini untuk menangani tata letak. Entah bagaimana saya meyakinkan dia untuk membiarkan saya "mengubahnya" sehingga dia memberi saya waktu ekstra. Saya menggunakan waktu itu sebagai gantinya menulis perpustakaan yang dirancang dengan baik untuk membantu tata letak. Bug dalam proyek baru ini benar-benar membutuhkan waktu 10 detik untuk menyelesaikannya. Saya bisa mengidentifikasi masalah bahkan sebelum melihat kode untuk melihat apa yang salah.

Saya pikir ini akan menghasilkan titik balik bagi manajer saya, tetapi yang saya dapatkan hanyalah tepukan di punggungnya dan dia pada dasarnya mengatakan kepada saya bahwa "Cara Anda juga berfungsi, saya kira."

Sejak itu saya mulai bekerja di toko lain dan semuanya menjadi lebih baik di sini. Intinya adalah, Anda tidak dapat mengubah pikiran mereka. Pergilah bekerja di tempat lain.


2
Setuju ... Tidak ada gunanya mencoba mengubah pikiran siapa pun di tempat Anda bekerja kecuali Anda dibawa sebagai pengembang senior / pemimpin tempat mereka mengharapkan ini dari Anda. Saya merasa seperti saya sedang bekerja di tempat Anda menggambarkan pertama kali Anda bekerja dan saya siap untuk terjun ke padang rumput yang lebih ramah
programmx10

Hal yang sama; Sepertinya saya selalu menemukan pekerjaan dengan rekan kerja bodoh yang benar-benar tidak mampu melakukan hal-hal dengan benar, dan ketika saya mencoba menjelaskan cara-cara yang lebih baik, saya agak hanya mendapatkan ini "Hah?" lihat atau alasan mengapa mereka tidak bisa melakukannya (misalnya kita tidak punya waktu untuk memperbaiki kode, itu perlu dilakukan), jadi tidak ada yang berubah dan saya merasa frustrasi harus berurusan dengan hal-hal yang ditulis dengan buruk.
Wayne Molina

1

Saya masih memiliki harapan, bahwa dalam ekonomi ada semacam proses evolusi, yang cepat atau lambat akan menendang perusahaan semacam itu keluar dari bisnis. Tetapi mungkin kecepatan tinggi kemajuan teknologi menghasilkan terlalu banyak relung baru, sehingga pesaing yang lemah pun masih dapat menemukan "makanan" yang cukup.

Jika Anda ingin meningkatkan peluang Anda untuk bekerja di tempat yang baik, carilah perusahaan yang memiliki produk yang mereka jual kepada banyak pelanggan alih-alih menulis sesuatu yang baru setiap beberapa minggu. Seharusnya ada lebih banyak minat dalam memiliki basis kode yang baik dan mampu menambahkan fitur baru tanpa melanggar kode yang ada sepanjang waktu.


1

Mengingatkan saya pada pasangan utama saya dari perguruan tinggi. Dia mengambil kelas desain VLSI, dan untuk pekerjaan rumahnya yang pertama muncul dengan komponen yang ada di urutan lebar mikrometer dan satu mil panjang. Simulasi berlalu dengan sempurna.

Jawabannya kepada kritikusnya adalah: "Yang saya tahu adalah omong kosong saya bekerja.".


1

Norma yang cukup baik adalah prinsip Pareto

Saya memiliki pengalaman dari proyek dengan aturan 80-20 dan itu bekerja dengan sangat baik. Saya pikir jawaban untuk pertanyaan ini "Di mana Anda menarik garis kesempurnaan Anda" juga bisa membantu.

Istilah "prinsip Pareto" juga dapat merujuk pada efisiensi Pareto. Prinsip Pareto (juga dikenal sebagai aturan 80-20, hukum segelintir orang penting, dan prinsip sparsity faktor) menyatakan bahwa, untuk banyak peristiwa, sekitar 80% efek berasal dari 20% penyebabnya. Pemikir manajemen bisnis Joseph M. Juran menyarankan prinsip tersebut dan menamakannya dengan ekonom Italia Vilfredo Pareto, yang mengamati pada tahun 1906 bahwa 80% tanah di Italia dimiliki oleh 20% populasi; ia mengembangkan prinsip itu dengan mengamati bahwa 20% polong polong di kebunnya mengandung 80% polong. Ini adalah aturan umum dalam bisnis; misalnya, "80% dari penjualan Anda berasal dari 20% dari klien Anda". Secara matematis, di mana sesuatu dibagikan di antara set peserta yang cukup besar, harus ada angka k antara 50 dan 100 sehingga "k% diambil oleh (100 - k)% dari peserta". Jumlah k dapat bervariasi dari 50 (dalam kasus distribusi yang sama, yaitu 100% populasi memiliki bagian yang sama) hingga hampir 100 (ketika sejumlah kecil peserta menghitung hampir semua sumber daya).Tidak ada yang istimewa tentang angka 80% secara matematis, tetapi banyak sistem nyata memiliki suatu tempat di sekitar wilayah ini dari ketidakseimbangan menengah dalam distribusi. Prinsip Pareto hanya secara tangensial terkait dengan efisiensi Pareto, yang juga diperkenalkan oleh ekonom yang sama. Pareto mengembangkan kedua konsep dalam konteks distribusi pendapatan dan kekayaan di antara populasi.

Tautan ke Sumber


Itu bagus tetapi bagaimana hubungannya dengan pertanyaan? Apakah Anda mengatakan 20% dari tempat kerja menghasilkan 80% dari perangkat lunak yang buruk?
Kirk Broadhurst

Tidak, jika perangkat lunak berfungsi 80% tidak masalah. Tingkat kesalahan yang diterima adalah 20%.
Amir Rezaei

0

Ketika saya meminta penulisan ulang beberapa kode yang saya tulis saat kami sedang mengeksplorasi spec, mereka menolaknya. Saya ingin menulis ulang kode karena kode diulangi di banyak tempat, tidak ada enkapsulasi dan butuh waktu lama bagi orang untuk mengubahnya.

Jangan tersinggung, tetapi sebagai manajer saya membaca pernyataan itu di suatu tempat di sepanjang baris:

"Ketika saya diminta dibayar dua kali untuk menulis ulang beberapa kode yang sudah saya tulis, perusahaan saya tidak mau membayar. Saya ingin uang tambahan untuk membersihkan kekacauan yang saya buat ketika saya menulisnya pertama kali, dan rekan-rekan marah kepada saya karena membuat hidup mereka sulit. "

Jika itu kode Anda sendiri yang Anda keluhkan - Anda tidak punya banyak hal untuk dipertanggungjawabkan.

MEMPERBARUI

Saya mengerti bahwa POV ini tidak populer. Tapi, saya pikir itu sama sekali tidak sesuai dengan tanggung jawab dan sikap pengembang profesional.

Jika Anda menulis kode bersih untuk memulai (dan ada banyak alasan untuk melakukan ini - terlepas dari apakah Anda berpikir kode Anda akan melihat penggunaan produksi atau tidak), maka Anda akan memiliki masalah ini jauh lebih jarang.

Jika Anda memasukkan kode bersih dan waktu refactoring dalam perkiraan Anda, Anda juga akan memiliki jadwal untuk menjaga agar basis kode tetap rapi. Jika, karena tekanan jadwal, Anda tidak mendapatkan waktu yang diperlukan - perkiraan masa depan Anda akan naik sebagai akibat dari berurusan dengan utang teknis yang timbul.

Pada titik tertentu, perkiraan masa depan Anda (atau ketidakpastian di sekitar perkiraan Anda) akan memberi Anda pengaruh untuk membantah penulisan ulang (ketika manajer Anda meminta Anda untuk membuat prosesnya berjalan lebih cepat). Jika tidak, maka terimalah bahwa bisnis telah menerima perkiraan Anda dan lebih suka membayar biaya yang sedang berlangsung daripada untuk penggantian. Itu murni keputusan bisnis - bukan keputusan teknis.

Ingat, waktu untuk menegosiasikan jadwal adalah sebelum Anda menulis kode - bukan setelahnya. Setelah kode ditulis (dan "berfungsi"), pelanggan, manajer, dan eksekutif tidak ingin melihat tagihan lain untuk "pemeliharaan" yang mendekati atau melebihi biaya asli. Jika Anda merasa kuat tentang hal itu seperti yang Anda pikirkan tentang bisnis, jangan ragu untuk menulis ulang pada waktu Anda sendiri - itulah yang Anda minta agar dilakukan oleh bisnis.

Dari sudut pandang manajer Anda, memberi Anda jadwal untuk menulis ulang menempatkan pantatnya di telepon. Ketika Anda gagal memberikan, atau meningkatkan produktivitas sebanyak yang Anda katakan - maka dia yang memegang tas itu. Dibandingkan dengan ketidaknyamanan yang relatif kecil saat mendengarkan Anda mengeluh, tebak yang mana yang akan lebih disukai.


2
Perhatikan bahwa "pada dasarnya menjelajahi spesifikasi." Jika, sebagai manajer Anda memberi saya spesifikasi terperinci dan saya perlu menulis ulang, salahku. Jika Anda TIDAK memberikan spesifikasi dan mengembangkannya seperti yang saya tulis, saya perlu refactor karena saya tidak akan mengetahui semua persyaratan di bagian kode sebelumnya.
q303

8
Saya ingin menurunkan jawaban ini sangat menyakitkan. Tapi saya tidak bisa ... Ini BENAR-BENAR bagaimana manajer berpikir. Terserah tim pengembang untuk memasukkannya ke dalam istilah yang dapat diterima manajer. Mengatakan "menulis ulang" walaupun hal itu berhasil akan memicu reaksi Mark setiap saat. Mungkin mengatakan "memantapkan" atau "menstabilkan" atau "selesai" akan kurang menggelegar. Manajer harus menyadari bahwa mereka telah berproduksi dengan kode yang tidak lengkap, dan terserah kepada mereka apakah mereka ingin menyelesaikan pekerjaan; terserah pengembang untuk meyakinkan mereka tentang biaya untuk tidak melakukannya.
Jeff Knecht

1
@ Jeff - tepat! Seorang kolega yang bijak pernah berkata kepada saya "jangan beri mereka kesempatan untuk mengatakan, itu semua tergantung pada bagaimana Anda mengucapkan pertanyaan".
ozz

2
Sikap Anda sebagai manajer berfungsi sampai pengembang asli pergi. Orang lain kemudian harus mengambil kodenya dan baik a) menghabiskan 10x selama bekerja pada perubahan daripada seharusnya, atau b) menghasilkan perubahan yang memperkenalkan bug yang mengerikan. Maka itu bukan seorang pembuat kode yang mengeluh tentang kodenya; itu adalah pengembang baru yang mengeluh tentang masalah yang Anda cegah agar tidak dipecahkan ketika mereka bisa diperbaiki dengan lebih mudah. Gagasan bahwa pengembang adalah "sumber daya" yang dapat dipertukarkan adalah sudut pandang yang sangat naif.
Semut

0

Jika itu jenis pekerjaan yang bisa Anda peroleh, fokus saja untuk menulis kode yang lebih baik setiap kali, daripada kembali dan menulis ulang kode lama. Masih ada kisaran kualitas yang bisa Anda pindahkan dalam ranah perekatan paket pihak ketiga.

Jika Anda punya waktu dan ingin memperbaiki kode komponen yang ada yang Anda pertahankan, tidak bisakah Anda melakukannya tanpa meminta izin, selama apa yang Anda lakukan berfungsi? Faktor waktu menjadi perkiraan Anda untuk proyek berikutnya yang menggunakan komponen.

Untuk pemrograman tingkat bawah, jika Anda tidak bisa mendapatkan kepuasan belajar dari pekerjaan Anda, mungkin sekarang saatnya untuk melihat proyek sumber terbuka?


Biasanya alasan utama mengapa orang tidak suka menyentuh kode jelek yang ada adalah bahwa kode ini berfungsi melalui banyak iterasi perbaikan bug / bandaid. Pergi dan menulis ulang - tanpa izin - seperti membuang semua perbaikan bug tersebut. Anda mengganti kode yang sudah teruji pertempuran untuk sesuatu yang baru keluar dari pabrik. Saya tidak akan melakukan itu tanpa meminta izin.
Kirk Broadhurst

0

q303, saya menemukan pertanyaan Anda menarik dan merasa Anda mungkin menemukan pertanyaan Programmer ini layak dibaca, tentang bagaimana meyakinkan manajer untuk membiarkan pengembang mengatasi utang teknis.

Saya pikir secara umum, ya, itu adalah norma. Memahami bahwa perangkat lunak yang berfungsi tetapi kurang optimal jauh lebih baik daripada perangkat lunak yang tidak berfungsi. Ada juga argumen bahwa definisi "bekerja" dapat bervariasi berdasarkan persepsi dan bias masing-masing individu. Ketika Anda menerapkan sistem baru, selalu ada seseorang yang akan mengatakan bahwa mereka merasa sistem yang lama lebih baik. Dan ketika Anda berbicara dengan pengembang, ia cenderung enggan mengaku telah bekerja pada perangkat lunak yang jelek.

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.