Jika calon pemberi kerja memberi tahu Anda bahwa mereka "memperbaiki bug yang direkrut karena pengembang membenci memperbaiki bug", Bagaimana menurut Anda? Apa yang mungkin menjadi perhatian Anda?
Pengembang benci memperbaiki bug? Saya pikir itu lebih mereka benci menemukan cara yang dapat diandalkan untuk mereproduksi bug, yang adalah untuk apa penguji. Jika Anda melakukan outsourcing untuk memperbaiki bug, Anda dapat melakukan outsourcing terhadap seluruh tim pengembangan. Tidak ada yang mengerti kode serta orang yang menulisnya sendiri .
Rob
1
Kedengarannya seperti ide yang buruk.
Andres F.
1
@AndresF. +1. Ini akan menciptakan lingkungan di mana devs hanya melempar omong kosong di dinding dan berharap itu menempel. Bukankah masalah mereka jika tidak, kan?
MrFox
Jawaban:
25
Memperbaiki bug kami sendiri sebenarnya membuat kami menjadi pengembang yang lebih baik . Dan itu adalah momen yang sangat menyenangkan bagi saya. Terutama ketika mereka dilaporkan dengan baik.
Jika mereka tidak suka memperbaiki bug, masalahnya ada di tempat lain.
Saya menduga masalahnya adalah bagaimana bug dirasakan oleh manajemen atau lebih buruk, oleh keputusan desain yang buruk dan / atau tidak ada pengujian (unit), menyebabkan perbaikan bug menyakitkan.
Mengalihtugaskan perbaikan bug mungkin akan memperburuk keadaan.
Pengembang mungkin tergoda untuk mengurangi kualitas. Siapa peduli? Beberapa pria lepas pantai ada di sana untuk membersihkan kekacauan mereka.
Sampai orang-orang lepas pantai menggantikan orang-orang darat.
@Aditya: tidak ada yang menakutkan di sini, ini PERSIS apa yang terjadi pada majikan terakhir saya. Petugas lepas pantai sudah cukup memperbaiki bug sepanjang waktu dan manajer mereka (amin kepadanya) mulai memberikan pelatihan. Pada satu titik mereka mendapat cukup baik untuk memulai refactor sederhana, pembersihan dll. Sementara itu di kantor utama tidak ada yang berubah. Saya dapat dengan mudah melihat bahwa dalam tahun depan orang-orang lepas pantai akan melakukan sebagian besar pekerjaan dan orang-orang kantor utama ... well ...
sayang
15
Pergi , lari ... cepat dan tidak pernah melihat ke belakang ...
Saya telah bekerja untuk perusahaan seperti itu, mereka pikir mereka pintar,
hei kita punya mereka semua bug tetapi senior kami mengeluh mereka menghabiskan terlalu banyak waktu untuk memperbaiki bug.
mari kita buka kantor di luar negeri dan biarkan yang lain berurusan dengan ini.
untuk seorang manajer yang terdengar seperti rencana yang sangat bagus dan para pengembang akhirnya dibebaskan untuk menangani tugas yang lebih menarik untuk menciptakan hal terbaik berikutnya !!
ho ... tapi tunggu ...
setelah dua tahun, mereka pergi dari tim 5 devs di kantor utama mereka yang menangani semuanya ke tim 2 yang membuat barang baru dan tim 30 yang menemukan dan memperbaiki bug.
Anda tahu apa ... tim perbaikan bug sedang berjuang, mereka tidak bisa mengikuti.
ini membuat "senior" sama sekali tidak dapat dihitung atas kesalahan mereka sendiri. Lebih buruk lagi, karena semua itu terjadi sejauh ini, manajemen juga tidak menyadari dan kualitas kode menurun sangat cepat dari tingkat kualitas yang sudah sangat buruk.
Ketika saya pergi, mereka sudah membuka dua kantor lagi untuk pemecah masalah bug dan mereka masih tidak bisa mengikuti pengembang baru yang menciptakannya. mereka benar-benar berpikir itu karena orang baru tidak cukup pintar ...
jadi ya, mulai sekarang, jika sebuah perusahaan mengatakan mereka mengalihdayakan perbaikan bug mereka ke kantor di luar negeri, percayalah padaku ... aku lari ... cepat.
Ini adalah metodologi manajemen Paper Bag .
Berdirilah di atas kereta api, tunggu kereta datang, ketika Anda melihatnya, letakkan kantong kertas di atas kepala Anda dan ... POOF .. kereta hilang !!. Ajaib!
Memiliki perusahaan membayar orang lain untuk membersihkan kekacauan saya terdengar seperti ide yang bagus kecuali ketika saya diharapkan untuk mengambil kode 'bersih' mereka dan menambahkan fitur baru. Dan jika mereka sangat kacau sehingga mereka tidak bisa memperbaikinya, Anda akan debugging debugging.
Tidak mendapatkan kompensasi yang memadai karena mereka harus mempekerjakan pengembang tambahan tidak diinginkan.
Menghabiskan waktu yang tidak proporsional untuk mendidik pengembang lain ketika Anda bisa memperbaikinya sendiri adalah kontra-produktif.
Sebagian dari saya merasa bahwa mereka yang membuat masalah harus menjadi orang yang memperbaikinya atau tidak ada insentif untuk menghindari membuat bug di tempat pertama.
Apakah pengembang tidak tertarik belajar dari kesalahan mereka? Bisakah Anda memperbaiki bug tanpa pengetahuan domain tertentu, dan apakah mitra outsourcing memiliki pengetahuan ini? Bagian yang memperbaiki adalah yang paling mudah, bagian analisis yang membutuhkan waktu. Dari sudut pandang saya itu adalah keputusan bodoh.
Jika calon pemberi kerja memberi tahu Anda bahwa mereka "memperbaiki bug yang direkrut karena pengembang membenci memperbaiki bug", Bagaimana menurut Anda? Apa yang mungkin menjadi perhatian Anda?
Saya akan lari jauh, jauh, jauh sekali. Pengembang selalu, selalu, selalu bertanggung jawab untuk memperbaiki bug sendiri. Makan makanan anjing adalah prinsip dasar teknik yang baik.
Lebih jauh, memperbaiki bug sama pentingnya, mungkin lebih dari pengembangan. Maksud saya, pengembangan adalah penulisan kode, pengujian dan debugging / perbaikan.
Apa yang saya dapatkan dari perusahaan ini adalah bahwa mereka memperlakukan perbaikan bug sebagai tugas kelas dua. Itu sendiri sangat mengganggu dan saya akan sangat mempertanyakan kualitas pekerjaan mereka (dan ergo, lingkungan kerja mereka.) Lebih mengganggu lagi adalah mereka mendelegasikan bagi mereka apa pekerjaan kelas dua bagi para pekerja di lepas pantai. Itu lebih mengganggu. Jelas ada stratifikasi sosial yang diabadikan dalam proses rekayasa mereka.
Cacat selalu disebabkan oleh root untuk perubahan, dan biasanya bug adalah tanggung jawab siapa pun yang memperkenalkan perubahan. Siapa yang lebih baik daripada pencetusnya untuk memahami sifat bug dan resolusinya?
Jika itu didelegasikan di seluruh dunia, bagaimana memastikan penulis asli tersedia untuk insinyur lepas pantai?
Apakah dia akan tersedia, meninggalkan insinyur lepas pantai yang tidak memiliki apa pun kecuali tumpukan bug dan tenggat waktu, tetapi tidak ada dukungan dari Metropole ? Jenis perbaikan bug apa yang mungkin bisa dilakukan seseorang? Siapa yang memperbaiki bug-nya? Dan apa yang mencegah pengembang Metropole belajar melalui perbaikan bug post-mortem?
Ada bajingan di semua bidang. Ini khususnya benar dalam perangkat lunak. Karena itu tidak bisa dihindari, satu-satunya pilihan Anda adalah bekerja dengan bajingan yang tahu lebih banyak dari Anda atau melakukan hal-hal yang benar. Perusahaan ini sepertinya tidak sesuai dengan deskripsi itu.
"Lebih jauh, memperbaiki bug sama pentingnya, mungkin lebih dari pengembangan." Saya tahu apa yang Anda maksud di sana, tetapi saya akan mengatakan lebih jauh: Saya tidak dapat memahami dikotomi semacam itu. Perbaikan bug adalah aspek intrinsik, fundamental dari pembangunan.
Dan Ray
1
@Dan - ya, pernyataan Anda jauh lebih benar. Tidak ada dikotomi seperti itu.
luis.espinal
4
Apakah mereka benar-benar mengharapkan sekelompok pengembang junior lepas pantai untuk dapat memperbaiki sekelompok kode pengembang senior? Rasanya seperti memiliki perawat memeriksa semua neuroligists bekerja dan mengulanginya di mana ia membuat mistikes. IDE BURUK!
Saya akan khawatir seberapa baik karyawan mereka benar-benar tahu kode yang mereka kembangkan.
Saya juga akan bertanya-tanya alasan ada cukup bug untuk membenarkan biaya tambahan yang dibawa. Saya juga akan khawatir tentang masa depan jangka panjang perusahaan, ada banyak artikel di web yang mengklaim perusahaan-perusahaan ini, menggunakan kode yang sama untuk beberapa proyek bahkan dalam industri yang sama.
Memperbaiki kode yang rusak adalah bagian dari proses penulisan kode yang memungkinkan Anda memiliki pemahaman yang lebih baik tentang kesalahan Anda 6 bulan lalu, jadi Anda tidak membuat kesalahan yang sama, jika beberapa pengembang lain memperbaiki kesalahan Anda bagaimana Anda mencegahnya bug terjadi lagi dan lagi?
Ini terdengar samar-samar seperti majikan saya sebelumnya, kecuali sedikit "calon majikan". Mereka telah kehilangan pengembang karena gesekan dan telah kehilangan terlalu banyak untuk mendukung produk yang sudah ada sambil menambahkan fitur baru yang diperlukan oleh perubahan undang-undang dan peraturan (60% dari pendapatan kantor berasal dari produk berbasis VB6, dan MS telah menyatakan bahwa runtuhnya VB6 tidak akan didistribusikan dalam sistem operasi masa depan, jadi akan seperti ketika Vista keluar - perebutan gila untuk memperbaiki keadaan). Kekuatan-yang-ingin ingin membawa perusahaan publik segera, jadi mereka membuat semua orang kelaparan sumber daya untuk membuat neraca terlihat lebih baik daripada itu - jadi mempekerjakan lepas pantai adalah satu-satunya cara untuk mendekati tinggal di pasar.
Berdasarkan pengalaman saya, kutipan tersebut mengatakan bahwa calon atasan Anda murah.
@Ramhound, David, Greg, Itu adalah tempat yang lebih baik ketika saya mulai, saya meninggalkan tempat itu pada akhir Desember (tak lama setelah ulang tahun ke 5 saya). Tidak ada yang dipekerjakan sejak saya dipekerjakan, dan dalam 2 tahun terakhir, 6 pengembang telah berhenti. Yang terbaru untuk berangkat sudah ada 11 tahun.
Tangurena
3
Itu tergantung apa yang mereka maksud dengan "memperbaiki bug". Jika ini memperbaiki bug selama siklus dev / test maka itu sangat aneh, ini adalah pekerjaan untuk pengembang asli. Jika, di sisi lain, itu berarti mereka telah mengalihdayakan pemeliharaan produk yang dirilis maka ini bukan hal yang aneh dan bukan sesuatu yang saya khawatirkan.
Poin baiknya, tidak ada orang lain yang membayangkan sudut itu.
Greg B
@ Greg & Steve - Saya tidak percaya itu penting untuk jujur. Jika mereka memperbaiki bug di katakan versi rilis bagaimana perbaikan itu bisa digabungkan ke dalam uji coba jika pengembang tidak menulis bug memperbaiki dirinya sendiri.
Ramhound
Jika perbaikan bug diperiksa di kontrol sumber, mereka dapat dengan mudah dipindahkan oleh tim lain ke cabang lain. Itu sama sekali bukan masalah besar.
Steve
Anda membuat poin yang baik meskipun saya benar-benar akan menyetujui skenario ini hanya dalam kasus di mana aplikasi adalah sistem warisan yang tidak lagi dikembangkan secara aktif tetapi perlu tetap berfungsi karena alasan tertentu. Katakanlah generasi baru yang merupakan penulisan ulang lengkap dari yang dipertanyakan.
Newtopian
2
Pengalaman saya adalah bahwa membawa tim eksternal setelah fakta akan menghabiskan waktu sebanyak hanya memperbaiki bug Anda sendiri - mereka harus dibawa ke kecepatan dan dibawa ke dalam proses pengembangan. Dan terus dengan kecepatan terus menerus. Koordinasi lebih sulit daripada menulis kode.
Jika saya akan bekerja pada basis kode, saya ingin beberapa jaminan bahwa semua orang dengan hak istimewa berkomitmen cukup kompeten. Ini termasuk beberapa orang di India, katakanlah, tetapi bukan yang biasanya tidak diikutsertakan.
Selain itu, sebagian besar bug saya berada di bagian kode yang lebih rumit, dan itu adalah yang paling tidak dimengerti oleh programmer lepas pantai sebelum menerapkan perbaikan bug.
Kebijakan ini sebenarnya ada secara tidak sadar di beberapa perusahaan. Saya bekerja untuk agen outsourcing; saya dan kolega saya adalah pemrogram yang lebih cakap daripada orang di tempat, mereka meminta kami untuk mengajari mereka cara menggunakan alat dll., tetapi sisi lain dari itu adalah bahwa kami akan melihat masalah dalam kode mereka lebih cepat daripada yang mereka lakukan.
Umumnya programmer klien secara fisik berada di gedung yang sama dengan setidaknya beberapa pengguna, sehingga mereka lebih cenderung mendapatkan konteks yang tidak menjangkau seluruh belahan bumi. Kami merasa ini bekerja dengan baik, bagian yang hilang bagi saya adalah bahwa mereka tidak meninjau kode kami sehingga ketika kontrak selesai mereka mungkin memiliki beberapa kejutan atau pertanyaan, bukan karena praktik buruk di pihak kami, tetapi hanya masalah biasa yang Anda miliki saat mengambil alih proyek orang lain.
Dalam kasus apa pun saya senang bahwa dalam kasus kami itu bukan kebijakan resmi, karena itu saya pikir itu akan mengikis programmer di tempat untuk menjadi sedikit lebih daripada BA.
Jawaban:
Memperbaiki bug kami sendiri sebenarnya membuat kami menjadi pengembang yang lebih baik . Dan itu adalah momen yang sangat menyenangkan bagi saya. Terutama ketika mereka dilaporkan dengan baik.
Jika mereka tidak suka memperbaiki bug, masalahnya ada di tempat lain.
Saya menduga masalahnya adalah bagaimana bug dirasakan oleh manajemen atau lebih buruk, oleh keputusan desain yang buruk dan / atau tidak ada pengujian (unit), menyebabkan perbaikan bug menyakitkan.
Mengalihtugaskan perbaikan bug mungkin akan memperburuk keadaan.
Pengembang mungkin tergoda untuk mengurangi kualitas. Siapa peduli? Beberapa pria lepas pantai ada di sana untuk membersihkan kekacauan mereka.
Sampai orang-orang lepas pantai menggantikan orang-orang darat.
sumber
Pergi , lari ... cepat dan tidak pernah melihat ke belakang ...
Saya telah bekerja untuk perusahaan seperti itu, mereka pikir mereka pintar,
hei kita punya mereka semua bug tetapi senior kami mengeluh mereka menghabiskan terlalu banyak waktu untuk memperbaiki bug.
mari kita buka kantor di luar negeri dan biarkan yang lain berurusan dengan ini.
untuk seorang manajer yang terdengar seperti rencana yang sangat bagus dan para pengembang akhirnya dibebaskan untuk menangani tugas yang lebih menarik untuk menciptakan hal terbaik berikutnya !!
ho ... tapi tunggu ...
setelah dua tahun, mereka pergi dari tim 5 devs di kantor utama mereka yang menangani semuanya ke tim 2 yang membuat barang baru dan tim 30 yang menemukan dan memperbaiki bug.
Anda tahu apa ... tim perbaikan bug sedang berjuang, mereka tidak bisa mengikuti.
ini membuat "senior" sama sekali tidak dapat dihitung atas kesalahan mereka sendiri. Lebih buruk lagi, karena semua itu terjadi sejauh ini, manajemen juga tidak menyadari dan kualitas kode menurun sangat cepat dari tingkat kualitas yang sudah sangat buruk.
Ketika saya pergi, mereka sudah membuka dua kantor lagi untuk pemecah masalah bug dan mereka masih tidak bisa mengikuti pengembang baru yang menciptakannya. mereka benar-benar berpikir itu karena orang baru tidak cukup pintar ...
jadi ya, mulai sekarang, jika sebuah perusahaan mengatakan mereka mengalihdayakan perbaikan bug mereka ke kantor di luar negeri, percayalah padaku ... aku lari ... cepat.
Ini adalah metodologi manajemen Paper Bag .
Berdirilah di atas kereta api, tunggu kereta datang, ketika Anda melihatnya, letakkan kantong kertas di atas kepala Anda dan ... POOF .. kereta hilang !!. Ajaib!
sumber
Memiliki perusahaan membayar orang lain untuk membersihkan kekacauan saya terdengar seperti ide yang bagus kecuali ketika saya diharapkan untuk mengambil kode 'bersih' mereka dan menambahkan fitur baru. Dan jika mereka sangat kacau sehingga mereka tidak bisa memperbaikinya, Anda akan debugging debugging.
Tidak mendapatkan kompensasi yang memadai karena mereka harus mempekerjakan pengembang tambahan tidak diinginkan.
Menghabiskan waktu yang tidak proporsional untuk mendidik pengembang lain ketika Anda bisa memperbaikinya sendiri adalah kontra-produktif.
Sebagian dari saya merasa bahwa mereka yang membuat masalah harus menjadi orang yang memperbaikinya atau tidak ada insentif untuk menghindari membuat bug di tempat pertama.
sumber
Apakah pengembang tidak tertarik belajar dari kesalahan mereka? Bisakah Anda memperbaiki bug tanpa pengetahuan domain tertentu, dan apakah mitra outsourcing memiliki pengetahuan ini? Bagian yang memperbaiki adalah yang paling mudah, bagian analisis yang membutuhkan waktu. Dari sudut pandang saya itu adalah keputusan bodoh.
sumber
Saya akan lari jauh, jauh, jauh sekali. Pengembang selalu, selalu, selalu bertanggung jawab untuk memperbaiki bug sendiri. Makan makanan anjing adalah prinsip dasar teknik yang baik.
Lebih jauh, memperbaiki bug sama pentingnya, mungkin lebih dari pengembangan. Maksud saya, pengembangan adalah penulisan kode, pengujian dan debugging / perbaikan.
Apa yang saya dapatkan dari perusahaan ini adalah bahwa mereka memperlakukan perbaikan bug sebagai tugas kelas dua. Itu sendiri sangat mengganggu dan saya akan sangat mempertanyakan kualitas pekerjaan mereka (dan ergo, lingkungan kerja mereka.) Lebih mengganggu lagi adalah mereka mendelegasikan bagi mereka apa pekerjaan kelas dua bagi para pekerja di lepas pantai. Itu lebih mengganggu. Jelas ada stratifikasi sosial yang diabadikan dalam proses rekayasa mereka.
Cacat selalu disebabkan oleh root untuk perubahan, dan biasanya bug adalah tanggung jawab siapa pun yang memperkenalkan perubahan. Siapa yang lebih baik daripada pencetusnya untuk memahami sifat bug dan resolusinya?
Jika itu didelegasikan di seluruh dunia, bagaimana memastikan penulis asli tersedia untuk insinyur lepas pantai?
Apakah dia akan tersedia, meninggalkan insinyur lepas pantai yang tidak memiliki apa pun kecuali tumpukan bug dan tenggat waktu, tetapi tidak ada dukungan dari Metropole ? Jenis perbaikan bug apa yang mungkin bisa dilakukan seseorang? Siapa yang memperbaiki bug-nya? Dan apa yang mencegah pengembang Metropole belajar melalui perbaikan bug post-mortem?
Ada bajingan di semua bidang. Ini khususnya benar dalam perangkat lunak. Karena itu tidak bisa dihindari, satu-satunya pilihan Anda adalah bekerja dengan bajingan yang tahu lebih banyak dari Anda atau melakukan hal-hal yang benar. Perusahaan ini sepertinya tidak sesuai dengan deskripsi itu.
Singkatnya, lari.
sumber
Apakah mereka benar-benar mengharapkan sekelompok pengembang junior lepas pantai untuk dapat memperbaiki sekelompok kode pengembang senior? Rasanya seperti memiliki perawat memeriksa semua neuroligists bekerja dan mengulanginya di mana ia membuat mistikes. IDE BURUK!
sumber
Saya akan khawatir seberapa baik karyawan mereka benar-benar tahu kode yang mereka kembangkan.
Saya juga akan bertanya-tanya alasan ada cukup bug untuk membenarkan biaya tambahan yang dibawa. Saya juga akan khawatir tentang masa depan jangka panjang perusahaan, ada banyak artikel di web yang mengklaim perusahaan-perusahaan ini, menggunakan kode yang sama untuk beberapa proyek bahkan dalam industri yang sama.
Memperbaiki kode yang rusak adalah bagian dari proses penulisan kode yang memungkinkan Anda memiliki pemahaman yang lebih baik tentang kesalahan Anda 6 bulan lalu, jadi Anda tidak membuat kesalahan yang sama, jika beberapa pengembang lain memperbaiki kesalahan Anda bagaimana Anda mencegahnya bug terjadi lagi dan lagi?
sumber
Ini terdengar samar-samar seperti majikan saya sebelumnya, kecuali sedikit "calon majikan". Mereka telah kehilangan pengembang karena gesekan dan telah kehilangan terlalu banyak untuk mendukung produk yang sudah ada sambil menambahkan fitur baru yang diperlukan oleh perubahan undang-undang dan peraturan (60% dari pendapatan kantor berasal dari produk berbasis VB6, dan MS telah menyatakan bahwa runtuhnya VB6 tidak akan didistribusikan dalam sistem operasi masa depan, jadi akan seperti ketika Vista keluar - perebutan gila untuk memperbaiki keadaan). Kekuatan-yang-ingin ingin membawa perusahaan publik segera, jadi mereka membuat semua orang kelaparan sumber daya untuk membuat neraca terlihat lebih baik daripada itu - jadi mempekerjakan lepas pantai adalah satu-satunya cara untuk mendekati tinggal di pasar.
Berdasarkan pengalaman saya, kutipan tersebut mengatakan bahwa calon atasan Anda murah.
sumber
Itu tergantung apa yang mereka maksud dengan "memperbaiki bug". Jika ini memperbaiki bug selama siklus dev / test maka itu sangat aneh, ini adalah pekerjaan untuk pengembang asli. Jika, di sisi lain, itu berarti mereka telah mengalihdayakan pemeliharaan produk yang dirilis maka ini bukan hal yang aneh dan bukan sesuatu yang saya khawatirkan.
sumber
Pengalaman saya adalah bahwa membawa tim eksternal setelah fakta akan menghabiskan waktu sebanyak hanya memperbaiki bug Anda sendiri - mereka harus dibawa ke kecepatan dan dibawa ke dalam proses pengembangan. Dan terus dengan kecepatan terus menerus. Koordinasi lebih sulit daripada menulis kode.
sumber
Jika saya akan bekerja pada basis kode, saya ingin beberapa jaminan bahwa semua orang dengan hak istimewa berkomitmen cukup kompeten. Ini termasuk beberapa orang di India, katakanlah, tetapi bukan yang biasanya tidak diikutsertakan.
Selain itu, sebagian besar bug saya berada di bagian kode yang lebih rumit, dan itu adalah yang paling tidak dimengerti oleh programmer lepas pantai sebelum menerapkan perbaikan bug.
sumber
Kebijakan ini sebenarnya ada secara tidak sadar di beberapa perusahaan. Saya bekerja untuk agen outsourcing; saya dan kolega saya adalah pemrogram yang lebih cakap daripada orang di tempat, mereka meminta kami untuk mengajari mereka cara menggunakan alat dll., tetapi sisi lain dari itu adalah bahwa kami akan melihat masalah dalam kode mereka lebih cepat daripada yang mereka lakukan.
Umumnya programmer klien secara fisik berada di gedung yang sama dengan setidaknya beberapa pengguna, sehingga mereka lebih cenderung mendapatkan konteks yang tidak menjangkau seluruh belahan bumi. Kami merasa ini bekerja dengan baik, bagian yang hilang bagi saya adalah bahwa mereka tidak meninjau kode kami sehingga ketika kontrak selesai mereka mungkin memiliki beberapa kejutan atau pertanyaan, bukan karena praktik buruk di pihak kami, tetapi hanya masalah biasa yang Anda miliki saat mengambil alih proyek orang lain.
Dalam kasus apa pun saya senang bahwa dalam kasus kami itu bukan kebijakan resmi, karena itu saya pikir itu akan mengikis programmer di tempat untuk menjadi sedikit lebih daripada BA.
sumber