Haruskah seorang pengembang menentang fitur yang tidak perlu atau berbahaya?

Apa sikap yang baik dari pengembang ketika mendiskusikan fitur baru, dan yaitu, fitur yang tidak kritis / dipertanyakan?

Katakanlah Anda sedang mengembangkan semacam bahasa seperti Java, dan bos berkata: "Kita perlu petunjuk sehingga pengembang bisa bermain-main dengan memori objek secara langsung!"

Haruskah pengembang menembak ide itu karena menambah kompleksitas dan kerentanan keamanan yang tak terbayangkan, atau haruskah dia melakukan apa yang diminta?

Ini mungkin bukan contoh yang baik, tetapi bagaimana dengan hal-hal yang lebih di daerah abu-abu, seperti menambahkan tombol yang memecah alur kerja, atau bertentangan dengan struktur internal program, dll?

Apa distribusi optimal "dapat melakukan" vs "tidak bisa melakukan" untuk programmer reguler?

EDIT: Pertanyaannya bukan tentang bos yang buruk: D

Saya lebih tertarik bagaimana orang mendekati masalah baru yang menambah jumlah masalah yang terlihat sementara mungkin sedikit berguna.

Seharusnya sikap umumnya:

1. ya kita akan melakukannya, sekrup kompleksitasnya
2. mungkin
3. tidak, pengerjaan ulang umum, dan implikasinya tidak membenarkan perubahan

Apa yang seharusnya menjadi reaksi pengembang yang baik?

Hal terbaik adalah mengadakan pertemuan dan menjabarkan pro dan kontra sebagai kelompok, dan berdasarkan itu membahas solusi terbaik. Jika Anda memiliki tim, mintalah mereka untuk menyetujui solusi. Setelah sebuah tim menyetujui sesuatu, manajer dan "bos" cenderung untuk pergi dengan solusi.

Jika bos Anda masih tidak setuju, maka Anda sudah melakukan semua yang dapat Anda lakukan: Anda telah membuat tim dan manajer Anda bersama dan membahas pro dan kontra dan meskipun demikian bos Anda memilih solusi yang berpotensi lebih rendah.

Kunci untuk ini adalah membahas pro dan kontra sebagai sebuah kelompok. Dengan melakukan itu Anda sedang mendiskusikan apa solusi terbaik dengan tim Anda, dan pada saat yang sama menunjukkan keputusan atasan Anda (sebelum dia membuat itu) tanpa reaksi politis dari berkeliling setelah fakta itu memberi tahu orang-orang mengapa Anda berpikir keputusan bos Anda adalah yang salah.

Ini adalah situasi tender yang melibatkan politik pekerjaan, tetapi dapat ditangani secara damai.

Jika bos Anda memberi tahu Anda untuk melakukan tugas-tugas bodoh, maka Anda harus (dengan ramah) menjelaskan mengapa itu bodoh.

Jika dia tidak mengerti maksudnya, maka Anda wajib melakukan hal-hal bodoh. Itu dia. Dia bosnya. Dalam hal demikian, Anda hanya dapat melakukan apa yang dikatakannya, atau berbicara dengan bosnya atau berganti pekerjaan.

Anda bisa memberi tahu bos bahwa meskipun secara teknis memungkinkan, akan diperlukan biaya sejumlah X dalam waktu dan uang yang dihabiskan untuk upaya analisis, desain, untuk menulis ulang kode yang ada, pengujian, pengujian regresi, ... Dan kemudian bertanya apakah fitur itu sepadan dengan itu . Terkadang jawabannya adalah "ya! Kita harus memiliki ini!", Terkadang itu akan "tidak, saya rasa tidak".

Jika fitur yang diminta melanggar beberapa prinsip inti dari aplikasi (seperti "Tambahkan tombol biru!" Ke UI yang ditentukan dan dirancang hanya memiliki tombol merah sesuai permintaan pelanggan) maka saya pikir itu OK untuk bertanya "Kenapa?" dan menyebutkan bahwa itu bertentangan dengan desain yang telah ditetapkan sebelumnya.

Pada akhirnya, hampir semuanya adalah "bisa dilakukan" (mungkin tidak sulit dari sudut pandang teknis untuk menambahkan tombol merah ke UI biru saja), ini lebih merupakan pertanyaan "harus dilakukan?"

Untuk menjawab pertanyaan Anda yang diedit, saya pikir jawabannya harus # 2, "Mungkin", sambil menunggu penyelidikan dan analisis lebih lanjut.

Anda tidak ingin menjawab # 1 "Ya, tanpa syarat" karena Anda bisa terjebak melakukan sesuatu yang Anda tidak mampu memberikan dalam jangka waktu yang diberikan.

Anda tidak ingin menjawab # 3 "Tidak, ini terlalu banyak pekerjaan" karena dengan begitu Anda terlihat tidak kooperatif dan sulit.

Dari sudut pandang pengembang: TIDAK PERNAH memberitahu siapa pun yang membayar tagihan bahwa mereka tidak dapat memiliki apa yang mereka inginkan. Sebagai gantinya, Anda dapat memberi tahu mereka bahwa mereka tidak dapat memilikinya untuk harga itu, atau bahwa mereka tidak dapat memilikinya persis seperti yang mereka bayangkan.

Untuk contoh "pointer" Anda; .NET, lingkungan kode yang dikelola, memiliki pointer. Mereka sangat diperlukan untuk banyak interoperabilitas dengan kode yang tidak dikelola. Namun, penggunaan "aman" dari mereka diatur dengan ketat, dan jika digunakan dalam kode "tidak aman", kode itu memerlukan izin keamanan yang lebih tinggi saat runtime. Jika Anda mengembangkan bahasa yang dikelola yang juga memerlukan akses memori langsung melalui pointer, Anda dapat membuat skema yang sama dengan menyusun di belakang layar di mana Anda bisa, menggunakan pointer yang dikelola hanya-baca di mana Anda tidak dapat secara otomatis menyusun, dan memungkinkan " true "pointer hanya di area yang paling tepercaya dari basis kode.

Untuk contoh GUI Anda: jika Anda tahu bahwa fitur baru akan "memecah" aliran kode saat ini, maka Anda dapat menguji untuk itu dan mengembangkannya lebih kuat untuk memutar kembali semua pekerjaan sebelumnya yang dilakukan oleh alur kerja. Klien Anda, dan kadang-kadang bahkan manajer Anda, biasanya tidak memiliki petunjuk atau minat dalam struktur program; jika sesuatu yang mereka inginkan sulit karena cara Anda menyusun program, maka menurut definisi struktur itu salah karena tidak memungkinkan Anda untuk melakukan apa yang diinginkan klien.

Dalam semua kasus, fitur baru ini dapat meningkatkan cakupan pekerjaan yang diperlukan di luar apa yang dipikirkan klien. Itu pada gilirannya akan membutuhkan perpanjangan untuk jadwal, lebih banyak uang, dan / atau pengurangan pekerjaan yang direncanakan lainnya.

Namun, jika Anda tahu cara untuk mencapai hasil dasar yang sama dengan cara yang lebih mudah atau lebih logis, maka itu dapat disarankan kepada klien. Meskipun mereka benar-benar ada, untungnya saya belum melihat klien yang menolak dengan pasti untuk mendengarkan masukan dari pengembang, terutama di lingkungan Agile di mana ada "pemilik produk" yang tugas satu-satunya adalah bergantung pada pengembangan berbagai detail yang diperlukan seperti ini.

Jika Anda menghabiskan waktu bertahun-tahun pemrograman untuk aplikasi besar, dan berpikir kritis tentang hal itu di sepanjang jalan, Anda akan mengembangkan perasaan yang disesuaikan dengan baik ketika suatu fitur akan menyebabkan masalah yang lebih besar daripada kegunaannya. Kata lain untuk ini adalah kebijaksanaan , dan seperti halnya dengan jenis kebijaksanaan lainnya, itu bisa menjadi tantangan untuk membuat mereka yang tanpa itu melihat nilainya.

Poster-poster lain berpendapat bahwa Anda harus mencoba untuk menghitung biaya masalah yang akan diperkenalkan oleh fitur yang bermasalah, dan itu adalah ide yang baik ketika memungkinkan, tetapi biasanya tidak. Biasanya hanya mungkin untuk memperkirakan biaya implementasi langsung. Bahkan itu seringkali sulit untuk fitur yang lebih besar. Adapun biaya masa depan, Anda berada di tempat yang sulit. Anda tidak tahu dengan pasti fitur apa yang akan dibutuhkan, atau berapa lama produk akan dalam pemeliharaan. Biayanya biasanya akan jauh lebih tinggi daripada yang bisa Anda backup dengan perkiraan berdasarkan fakta keras.

Semakin banyak kompetensi yang Anda tunjukkan di masa lalu, semakin banyak kelonggaran Anda harus mendeklarasikan fitur sebagai ide yang buruk. Itu hanya bisa datang dengan waktu dan catatan keberhasilan yang ditunjukkan. Karena itu, Anda harus selalu mengungkapkan keinginan untuk memenuhi permintaan, karena itulah yang diinginkan klien Anda. Anda harus mengekspresikan reservasi berdasarkan pengalaman Anda, dan begitu Anda memilikinya, itu menjadi masalah di 90% kasus karena Anda akan memulai percakapan yang sampai ke akar masalah, yaitu: Mengapa mereka meminta Anda untuk menambahkan fitur ini di tempat pertama? Pada titik itu Anda dapat menawarkan alternatif, atau mungkin setuju bahwa meskipun fitur yang diminta akan menimbulkan masalah, masih diperlukan.

Tentu saja mungkin saja Anda salah. Bukankah rekayasa perangkat lunak menyenangkan?

Karena pertanyaannya cukup samar, saya akan menggeneralisasi sedikit dengan tanggapan saya.

Selalu tanyai mereka, tapi dengarkan alasan mereka. Terkadang, orang hanya lupa tentang kepraktisan fitur atau berapa lama pemrograman akan berlangsung. Di sisi lain, kita kadang-kadang terjebak dalam mentalitas programmer untuk menjadi efisien / tanpa embel-embel / etc dan kita lupa bahwa apa yang kita anggap tidak penting untuk proyek sebenarnya bukan untuk klien.

Jika mereka memiliki alasan yang bagus, beri tahu mereka berapa lama waktu yang dibutuhkan untuk memprogramnya dan semua kemungkinan tonjolan yang akan Anda temui selama implementasi dan lihat apakah mereka masih ingin melanjutkannya. Kalau tidak, nyatakan mengapa Anda tidak berpikir itu ide yang bagus dan lihat apa reaksi mereka. Bilas dan ulangi.

Kebanyakan sudah dikatakan, tetapi ada satu hal yang ingin saya tekankan di lingkungan kerja saya saat ini. Saya bekerja untuk perusahaan yang merupakan kontraktor untuk perusahaan lain dan aplikasi yang terkait dengan proses bisnis (untuk jumlah yang adil mereka mendorong penjualan dan komunikasi pelanggan).

Proses bisnis bersama dengan produk yang menyertainya dapat (setidaknya jika perusahaan cukup besar) sangat kompleks. Untuk tingkat tertentu, jika Anda memodelkan hal yang kompleks, aplikasi yang dihasilkan akan memiliki kompleksitas yang berkaitan. Karena sebagian besar individu pelaku bisnis hanya melihat bagian mereka dari proses, aplikasi / proses yang lengkap dibangun di atas kompleksitas yang lebih besar daripada apa yang terlihat oleh satu pengguna saja.

Maksud saya adalah, bahwa ketika persyaratan bisnis baru muncul, itu akan bekerja untuk orang-orang bisnis, karena tidak meningkatkan kompleksitas yang jauh lebih tinggi, tetapi mungkin memiliki dampak yang lebih besar pada keseluruhan sistem. Menurut pendapat saya ini bukan alasan untuk menentang perubahan itu. Ini adalah titik yang tepat untuk membahas upaya (dan biaya) dengan pelanggan. Mungkin tidak akan menghentikan pelanggan untuk memiliki fitur yang dibangun, tetapi pada saat mereka akan merasakan aplikasi dan beberapa diskusi tentang "kamu, kamu semahal itu!" akan jauh lebih sedikit pilih-pilih.

Saya tidak tahu apakah Anda berada dalam situasi yang sebanding, tetapi saya telah belajar bahwa situasi pemangku kepentingan tidak selalu memiliki kompleksitas yang sama, seperti yang dihadapi pengembang dan arsitek sistem TI. Dalam situasi itu komunikasi membantu kedua belah pihak.

Maaf, tapi pertanyaan ini terdengar seperti anak di bawah umur yang meminta nasihat kebapakan. Jika ini masalahnya, pengembang yang baik perlu merangkul perintah-perintah ini:

• Tetap setia pada diri sendiri. Jika nyali Anda merasa tidak nyaman tentang suatu fitur, sampaikan kekhawatiran Anda secara jelas. Kemungkinan bagus bahwa tim hanya menunggu pembukaan.
• Jangan mencoba mengganti pengalaman dengan aturan praktis yang berpengalaman. Bagi Anda, setiap situasi berbeda, setiap fitur adalah baru. Ini adalah nilai tambah yang tidak dimiliki senior Anda.
• Pengembangan perangkat lunak bukanlah ilmu pasti, itu tidak akan pernah terjadi. Karena itu, kumpulkan kebijaksanaan, bukan perilaku.
• Terima kekalahan. Jika tim setuju sebaliknya, jangan ulangi kekhawatiran Anda dan mual.
• Berpikir positif. Jika ide tersebut benar-benar meminta 'menembaknya', cobalah untuk menemukan dan beri nama aspek positif sebelum Anda membuat daftar kekurangannya.
• Pelajari cara berinteraksi dengan orang. Kami pengembang sering menempatkan pengetahuan teknis di atas kompetensi sosial. Kemampuan teknis memuncak pada awal kehidupan, tetapi kompetensi sosial dapat terus tumbuh sampai pensiun.

Saya percaya mendorong kembali persyaratan yang buruk. Tetapi saya juga percaya bahwa ketika Anda telah memberikan yang terbaik untuk menjelaskan mengapa mereka buruk dan mereka masih menginginkannya, maka Anda setuju dan melakukan pekerjaan Anda.

Sebagai contoh, saya memiliki orang yang menginginkan persyaratan yang sama-sama eksklusif dari sesuatu yang sudah dilakukan aplikasi. Jika saya melakukan itu, maka ini akan, dijamin 100%, rusak. Jadi saya mengirim persyaratan kembali dan memberi tahu mereka bahwa ini akan melanggar aturan bisnis lain yang sudah kita miliki dan apakah mereka juga ingin mengubah aturan ini? Seringkali kelompok kecil yang muncul dengan persyaratan tertentu tidak memiliki akses ke gambaran yang lebih besar tentang apa yang dapat dilakukan oleh aplikasi lainnya. Sebagian besar waktu ketika saya mengirim salah satu dari ini kembali, pelanggan telah menyadari bahwa aturan awal lebih penting dan memutuskan bahwa perubahan yang mereka inginkan tidak sepadan. Ketika mereka memutuskan untuk melakukan perubahan, mereka melakukannya setelah berkonsultasi dengan orang-orang yang mendorong persyaratan awal.

Terkadang hanya mengajukan pertanyaan klarifikasi akan membuat mereka melihat masalah tidak sesederhana yang mereka kira. Terkadang Anda ingin bertanya mengapa mereka menginginkan sesuatu dan sampai pada kebutuhan nyata yang mendorong perubahan. Setelah Anda memahaminya, seringkali lebih mudah untuk melihat solusi alternatif yang berfungsi untuk Anda sebagai pengembang dan memenuhi kebutuhan mereka. Jika Anda dapat menyajikan solusi dalam hal bagaimana itu akan lebih memenuhi kebutuhan mereka daripada saran awal, Anda telah sangat meningkatkan peluang Anda agar perubahan Anda diterima.

Kadang-kadang ketika perubahan akan membuat kekacauan pada tingkat dasar dalam desain Anda, hanya memberi mereka perkiraan jam baru dari perubahan yang akan cukup untuk membuatnya dimatikan. Jika Anda mengombinasikannya dengan penilaian risiko yang menunjukkan fungsionalitas kritis apa yang mungkin Anda perkenalkan dengan bug baru dengan memberi tahu mereka bahwa diperlukan waktu 6 minggu upaya khusus oleh 3 orang, tiba-tiba itu tidak begitu penting lagi.

Tetapi kadang-kadang Anda memberi tahu mereka ini bukan ide yang baik dan mengapa dan mereka masih berkata, "Sayang sekali kami membutuhkannya." Anda memenangkan beberapa dan kehilangan beberapa dan kadang-kadang kebutuhan bisnis benar-benar telah berubah dan aplikasi harus mengakomodasi itu. Setelah keputusan diselesaikan, bukan lagi waktu untuk mempertanyakan apa yang Anda lakukan dan waktu untuk melanjutkannya. Jika Anda telah mendokumentasikan keberatan Anda, maka Anda secara pribadi masih harus berada di tempat yang baik ketika melebihi anggaran dan menyebabkan bug baru dan lebih menarik. Dan mereka bahkan mungkin lebih bersedia untuk mendengarkan Anda lain kali ketika Anda telah membangun rekam jejak yang benar dalam hal-hal semacam ini.

Kunci untuk memenangkan banyak diskusi ini (tidak ada yang memenangkan semuanya) adalah pertama-tama membangun rekam jejak untuk mengetahui apa yang Anda bicarakan. Selanjutnya kirim dokumen tertulis yang menyatakan kekhawatiran Anda (banyak manajer berisiko merugikan, mereka lebih cenderung tidak ingin seseorang memiliki dokumen yang membuktikan mereka salah nanti, sehingga mereka lebih memperhatikan apa yang Anda tuliskan secara tertulis) dan akhirnya untuk memastikan mereka memahami semua biaya (bukan hanya jam, tetapi risiko keamanan, memperkenalkan bug baru, tenggat waktu yang hilang, dll.) membuat perubahan. Perubahan tidak gratis dan mereka perlu memahaminya. Kunci selanjutnya adalah melakukan ini seperti orang dewasa dan tidak seperti anak yang merengek ("tapi saya tidak ingin menggunakan ... karena saya tidak suka itu"). Buat alasan bisnis untuk tidak melakukannya dan Anda akan mendapatkan lebih jauh dalam mendorong kembali persyaratan yang buruk.

Jika saya membaca Anda dengan benar, pertanyaan sebenarnya adalah tentang kompleksitas yang tidak diketahui. Awalnya saya membaca pertanyaan Anda sebagai, "Saya melihat risiko yang sangat besar kemungkinan kelebihan kompleksitas tetapi bos tidak" Tapi Anda mengatakan bahwa bos bukan masalah, jadi saya anggap Anda tidak yakin apa risikonya. menambahkan kompleksitas yang tidak dapat diterima adalah.

Dalam hal ini, saya akan merekomendasikan semacam strategi mitigasi risiko. Gambar yang Anda pertimbangkan untuk menambahkan layanan WCF / web ke API Anda, yang bisa luar biasa atau banyak kerumitan tanpa imbalan:

• tambahkan fitur pada cabang. Jika berhasil, gabungkan. Jika itu berubah menjadi sarang tikus, bunuh saja.
• jalankan proyek satu halaman baru dan lakukan pembuktian konsep. Jika Anda tidak dapat melakukan pembuktian konsep dalam waktu singkat, maka jatuhkan. Jika bukti konsep berhasil, buat lebih besar dan integrasikan dengan Anda
• menjelajahi web untuk orang-orang yang mengeluh tentang fitur atau teknologi itu. Di mana ada banyak cengkeraman yang terjadi, sebuah teknologi mungkin merupakan beberapa risiko nyata dari kompleksitas yang berlebihan. Java Beans dan COM + mungkin, tua, tetapi contoh fitur yang bagus yang benar-benar menambah kerumitan dan mungkin atau mungkin tidak disampaikan pada sisi manfaat dari persamaan

Berdebat tidak. Diskusikan mungkin ya. Tetapi harus diperlakukan sebagai tambahan untuk spesifikasi dan diprioritaskan dengan fitur lain. Jika Anda tahu bahwa permintaan akan menambah jumlah waktu dan kompleksitas yang tidak wajar untuk diimplementasikan, maka nyatakan hal itu di muka. Bukan sebagai oposisi untuk melakukan permintaan itu, hanya sebagai penjelasan tentang apa yang Anda pikir perlu untuk diterapkan.

Itu sangat tergantung pada permintaan. Implementasi pointer cukup besar untuk mempengaruhi seluruh proyek sehingga manfaatnya harus ditimbang jika diberi pilihan.

Menerapkan tombol yang merusak aliran. Mungkin bukan masalah besar jika formulir dapat ditata sedemikian rupa sehingga tombolnya opsional. Sebenarnya saya telah melakukan hal ini. Saya menambahkan tombol tetapi juga mengumpulkan informasi yang cukup sebelumnya bahwa tombol menjadi opsional. Pengguna yang mengharapkannya ada di sana menggunakannya dan mereka yang menyadari itu hanya mubazir tidak.

Ini semua tentang keseimbangan dan mengetahui kapan harus memilih pertempuran Anda. Beberapa hal lebih mudah diterapkan begitu saja dibandingkan berurusan dengan aspek sosial karena tidak memasukkannya.

Masalah yang saya lihat adalah penggunaan kata berdebat.

Anda harus mengemukakan masalah desain dan alasan di baliknya, tetapi berhati-hatilah karena programmer cenderung bersikap defensif tentang posisi yang telah mereka ambil dan memperdebatkan poin hanya untuk berdebat (Terkadang). Saya harus menghentikan diri saya untuk sedikit berdebat - dan saya tidak selalu berhasil. Juga seiring bertambahnya usia saya menemukan saya salah lebih sering daripada sebelumnya - atau lebih buruk saya tidak menyadari seberapa sering saya salah :)

Jika Anda memiliki persyaratan yang dinyatakan dengan jelas (bahasa harus aman, kami membutuhkan petunjuk untuk mengakses rutinitas lawas) maka Anda dapat mempresentasikan bagaimana kedua persyaratan tersebut bertentangan dan bertanya mana yang lebih penting. Setelah Anda memiliki persyaratan dan alasan di baliknya, Anda bahkan dapat menemukan solusi yang sangat berbeda yang mendukung kedua persyaratan (JNI - agak).

Jika tidak, mungkin ini saat yang tepat untuk menyusunnya!

1. Sadarilah bahwa Anda tidak tahu segalanya dan tidak bisa melakukan semuanya.

2. Jika Anda yakin itu adalah ide yang buruk, katakan apa yang buruk.

3. Jika mereka mencoba memaksakannya pada Anda, katakan baik - Perlu lebih banyak waktu untuk menganalisis, jika Anda membutuhkan lebih banyak waktu atau katakan bahwa kami belum menemukan solusi yang baik untuk masalah ini.

4. Jika mereka masih bersikeras menerapkan ide buruk, dapatkan pengakuan dari mereka bahwa Anda telah menyarankannya termasuk alasan Anda. Anda bahkan dapat mengirim email yang merangkum diskusi dengan salinan ke manajer Anda. Ini mungkin menghemat ** Anda nanti.

Dalam skenario yang ideal, Anda akan memiliki Pengembang Utama yang membuat keputusan akhir di sisi teknis dan Pemimpin Bisnis yang membuat keputusan akhir di sisi bisnis. Ini akan menjawab dua pertanyaan utama:

1) Apa? Apa yang diinginkan pelanggan?

2) Bagaimana? Bagaimana kita mencapai ini dari perspektif teknologi.

Apa yang diinginkan pelanggan adalah pembuat keputusan utama karena merekalah yang membayar tagihan

Sebagai pengembang, Anda seharusnya tidak terlalu peduli persyaratan mana yang diminta untuk diterapkan.

Namun, Anda harus menjelaskan jika ada sesuatu yang tidak realistis dan jika ada cara yang lebih baik.

Terkadang permintaan pelanggan yang sebenarnya (berasal dari politik pelanggan internal). Maka tidak ada harapan dan harus dilakukan (tetapi manajemen juga harus mempertimbangkan apakah melanjutkan proyek tersebut atau apakah mereka harus menegosiasikan kembali harga.)

Ini hampir merupakan tugas sehari-hari bagi saya, dan sebenarnya saya senang.

Jika Anda memiliki perubahan untuk memberikan pendapat Anda tentang apakah persyaratan tertentu harus atau tidak harus menjadi bagian dari aplikasi, orang non teknis akan mengharapkan Anda untuk mengisi dengan pengetahuan teknis Anda (misalnya "menggunakan pointer akan membuat aplikasi tidak stabil" atau "menggunakan parameter GET untuk tujuan X adalah risiko keamanan "). Rekan teknis juga akan menghargai umpan balik Anda tentang beberapa keuntungan atau kerugian tertentu yang mungkin tidak mereka pikirkan.

Tentu saja, itu keras ketika semua orang ingin fitur X dan Anda akhirnya mengatakan "itu mungkin tidak baik", tetapi pada akhirnya, semua orang mencoba untuk membuat aplikasi yang aman, kuat dan stabil (dapat dipertahankan, fleksibel, dll ... ) dan setiap suara harus diperhitungkan.

Menjawab pertanyaan Anda, itu bukan bagian dari pekerjaan pengembang (yaitu, mengembangkan), tetapi merupakan "ekstra" yang memberikan kualitas dan kerja tim.

Jika Anda berada dalam posisi untuk memahami kontra melakukannya (kompleksitas, kurangnya kegunaan, dll.), Maka adalah kepentingan terbaik semua orang bagi Anda untuk menjelaskannya sesuai kemampuan Anda. Seringkali non-pengembang tidak mengerti masalah menambahkan fitur baru. Mudah bagi mereka karena mereka tidak perlu melakukan apa pun atau bahkan memikirkannya.

Namun, jika kekuatan yang memutuskan bahwa fitur baru akan ditambahkan, maka Anda harus melakukan pekerjaan sebaik mungkin. Ini sebuah tantangan.

Dan, jika fitur baru terlalu bodoh atau lingkungan kerja terlalu jelek, maka saatnya mencari pekerjaan lain.