Seberapa umumkah sebuah tim menulis semuanya sendiri? [Tutup]

Dalam sebuah wawancara baru-baru ini saya bertanya kepada pewawancara "bagaimana Anda mengevaluasi teknologi dan perpustakaan baru (seperti SignalR) dan membawanya untuk digunakan?". Mereka mengatakan tidak, bahwa sebaliknya mereka menulis semuanya sendiri sehingga mereka tidak harus bergantung pada orang lain.

Perusahaan itu tidak bekerja untuk pemerintah atau kontraktor pertahanan atau pada proyek yang kritis terhadap keselamatan atau semacamnya. Mereka hanya rata-rata, perusahaan pengembangan perangkat lunak menengah Anda.

Pertanyaan saya adalah: seberapa umum bagi tim untuk menulis semuanya sendiri? Haruskah saya khawatir dengan tim yang melakukannya?

Sunting - Kebanyakan setiap tanggapan mengatakan ini adalah sesuatu yang harus diperhatikan. Akankah wawancara kedua menjadi waktu yang tepat untuk meminta mereka mengklarifikasi / mengulangi posisi mereka dalam menulis segala sesuatu di rumah?

Sikap tidak pernah menggunakan perpustakaan pihak ketiga tidak masuk akal. Menulis semuanya sendiri adalah penggunaan waktu perusahaan Anda yang mengerikan, kecuali jika ada persyaratan bisnis yang ketat bahwa setiap baris dalam basis kode ditulis oleh karyawan perusahaan - tetapi itu adalah skenario yang tidak biasa, terutama untuk perusahaan sektor swasta seperti Anda sudah jelaskan.

Jawaban yang lebih rasional dan menyeluruh mungkin bahwa mereka hanya akan menggunakan perpustakaan pihak ketiga yang:

• Penuhi kebutuhan kode yang seharusnya mereka tulis sendiri
• Tersedia di bawah lisensi yang kompatibel dengan model bisnis perusahaan
• Termasuk tes
• Melewati tinjauan kode

Jika kriteria tersebut dipenuhi (dan menurut pengalaman saya tinjauan kode sangat fleksibel terutama di hadapan tes yang baik), Anda tidak lagi "bergantung pada orang lain" - Anda mengandalkan yang ada, tersedia, dan lebih baik kuat kode.

Jika kode tersebut adalah open source, maka dalam kasus terburuk, pustaka pihak ketiga menjadi tidak terawat. Tapi siapa peduli? Tes membuktikan bahwa perpustakaan sesuai dengan kebutuhan Anda!

Selain itu, keengganan untuk membangun perpustakaan pihak ketiga secara serius menghambat produktivitas programer. Katakanlah perusahaan sedang menulis aplikasi web dan menolak untuk menggunakan (misalnya) jQuery, jadi alih-alih tulis pustaka lintas-browser alternatif mereka sendiri untuk menyederhanakan manipulasi DOM. Dengan hampir pasti kita dapat menganggap bahwa implementasinya:

• Akan memiliki API asing untuk pengembang yang sudah akrab dengan jQuery
• Tidak akan terdokumentasi dengan baik sebagai jQuery
• Tidak akan memiliki hasil Google yang relevan ketika mengalami masalah menggunakan perpustakaan
• Tidak akan teruji di lapangan seperti jQuery

Semua poin tersebut adalah hambatan utama terhadap produktivitas programmer. Bagaimana sebuah bisnis mampu melepaskan produktivitas seperti itu?

Anda telah memperbarui pertanyaan Anda untuk menanyakan apakah ini pantas untuk diajukan dalam wawancara kedua. Tentu saja.

Mungkin Anda salah menafsirkan jawaban pewawancara Anda dalam wawancara pertama, atau mungkin pewawancara hanya salah menjelaskan posisi perusahaan dan pewawancara baru dapat mengklarifikasi itu.

Jika Anda menjelaskan bahwa Anda khawatir tentang sikap mereka pada perpustakaan eksternal, setidaknya ada dua hasil yang mungkin:

• Mereka terbuka untuk berubah, dan kekhawatiran Anda tentang proses mereka membuat Anda terlihat lebih baik daripada beberapa kandidat lainnya.
• Mereka tidak terbuka untuk berubah, dan mereka menganggap Anda sebagai "jenis pengembang yang tidak ingin kami pekerjakan." Tidak masalah, itu bukan tempat yang Anda inginkan untuk bekerja.

Tampaknya sangat tidak kompetitif. Saya telah bekerja di toko-toko yang memutuskan untuk melewatkan perpustakaan open-source standar seperti Hibernate dan roll sendiri karena beberapa fitur yang hilang "kritis". Pada akhirnya perangkat lunak itu sangat mahal untuk dibangun dan dirawat. Tentu saja biaya perpustakaan di rumah terlalu diremehkan. Dan sementara perpustakaan in-house ditulis, perpustakaan standar maju pesat, menambahkan fitur-fitur baru yang tidak tersedia di perpustakaan in-house. Pada akhirnya, pekerjaan yang akan memakan waktu satu jam menggunakan perpustakaan standar sebagai gantinya butuh dua hari. Dan itu buruk bagi karier pengembang, karena dunia melewatinya. Saya akan menghindari toko seperti itu. Saya suka menyampaikan, dan tidak memiliki kesabaran untuk menulis ulang ketika saya bisa menggunakan kembali.

Toko itu memiliki penyakit bernama Not Invented Here . Merupakan alasan yang bagus untuk mengakhiri wawancara di tempat dan segera pergi. Ini hanya dapat disembuhkan dengan pembersihan rumah dari atas ke bawah yang sangat tidak mungkin terjadi.

Untuk menjawab pertanyaan Anda, itu jauh lebih umum daripada yang Anda pikirkan dan itu jelas alasan untuk khawatir.

Ya, pasti khawatir! Itu berbau arogansi dan kebodohan (maaf kasar). Setiap programmer dengan setengah otak akan menggunakan perpustakaan seperti signalR alih-alih menulis sendiri. Sama sekali tidak ada gunanya membuang waktu Anda memecahkan masalah yang sudah dipecahkan. Saya mungkin akan mencoba mencari tahu lebih banyak informasi dulu - mereka mungkin telah salah paham dengan Anda (mungkin akan sulit jika wawancara selesai!)

Saya memiliki beberapa teman yang keduanya (sebentar) bekerja di rumah-rumah perangkat lunak tanpa sindrom di sini . Jadi mentalitas ada di luar sana.

Pengamatan yang mereka berdua lakukan adalah seputar budaya pendekatan yang dipupuk dalam tim pengembangan. Mereka berdua akhirnya bekerja dengan orang-orang yang cukup picik dalam hal pandangan mereka tentang pengembangan perangkat lunak, dan orang-orang yang tidak benar-benar terdorong untuk mempelajari hal-hal baru dan mendorong kualitas. Terlepas dari tahap apa Anda dalam karir Anda, Anda selalu ingin bekerja di suatu tempat di mana Anda memiliki kesempatan untuk belajar hal-hal baru dari rekan-rekan Anda. Namun lingkungan semacam ini pada umumnya tidak ditemukan di tempat-tempat yang ingin menggulung semuanya sendiri.

Tidak umum di mana saya tinggal, dan saya tahu banyak perusahaan melalui rekan kerja. Saya akan mengatakan "tidak, terima kasih" dari saya.

Saya tidak akan memuntahkan poin bagus yang sudah dibuat, tetapi saya akan menambahkan satu hal.

Mereka baru saja membuat perekrutan jauh lebih sulit.

• Semua karyawan baru memiliki kurva belajar yang bahkan lebih curam daripada hanya bagian utama dari perangkat lunak / domain
• Kandidat terbaik akan ditunda karena mereka tidak ingin keterampilan mereka menjadi tidak digunakan.
• Orang tidak akan tinggal lama setelah mereka menyadari betapa buruknya tidak bisa menggunakan alat favorit mereka, dan pergantian staf mahal

Sekarang tentu saja akan ada orang yang menyukai tantangan, tapi saya pikir mereka akan menjadi minoritas.

Dan juga, akan ada beberapa perusahaan yang beroperasi pada "skala Internet", Amazon, Facebook, dll., Di mana mereka memiliki kebutuhan adat yang gila, tetapi sekali lagi ini adalah minoritas.

Saya tidak berpikir perusahaan perangkat lunak dapat bertahan hari ini tanpa bergantung pada pihak ketiga dan / atau perangkat lunak open source, dan agar tetap kompetitif mereka tentu saja perlu secara aktif melacak teknologi baru. Namun, sering kali ada alasan bagus untuk setidaknya mengambil pandangan yang agak defensif.

Sebagai contoh, jika Anda menjual perangkat lunak dan mengklaim untuk memberikan dukungan 24/7 dan secara hukum bertanggung jawab atas perangkat lunak Anda untuk beroperasi dengan benar, maka Anda harus memiliki ide yang sangat tepat tentang apa yang akan terjadi jika ada masalah dengan perangkat lunak di, katakanlah, sebuah pabrik di mana 1 jam waktu penghentian produksi mungkin memakan biaya jutaan dolar, dan kemudian bug serius terjadi di perpustakaan sumber terbuka yang Anda gunakan. Percayalah, Anda akan melakukan penilaian perangkat lunak yang sangat teliti.

Dari apa yang telah Anda tulis, skenario ini tampaknya tidak menjadi inti masalahnya.

Jika Anda adalah perusahaan berbasis teknologi dengan ukuran tertentu, maka Anda akan semakin banyak mengembangkan teknologi Anda sendiri, misalnya: google mengembangkan banyak jika tidak sebagian besar atau tidak semua perangkat lunak mereka saat membuka sumber sebagian besar darinya dalam upaya untuk menjadikannya standar industri.

Untuk perusahaan yang lebih kecil, akan tampak seperti buang-buang waktu ketika mereka mencoba untuk mengirim produk tertentu dengan logika bisnisnya sendiri, dan dalam pengalaman saya, saya belum pernah melihat perusahaan kecil-menengah melakukannya.

Ini menjadi lebih rumit ketika Anda berbicara tentang basis kode yang sangat terspesialisasi, misalnya: algoritma enkripsi - beberapa orang memiliki pemahaman dasar tentang bagaimana mereka bekerja, tetapi bagian rumit dari benar-benar menerapkan solusi akan tampak seperti menembak diri sendiri di kaki kecuali Anda menyewa seorang cryptographer yang berspesialisasi dalam hal-hal seperti itu.

Beberapa perusahaan mengizinkan kebebasan untuk membuat proyek sumber terbuka Anda sendiri, yang tampaknya lebih sesuai.

Saya pribadi tidak akan pergi ke tempat dengan budaya seperti itu.

Apa yang Anda dapatkan adalah kesempatan yang sangat bagus untuk memasuki wawancara kedua dan mengajukan beberapa pertanyaan sulit kepada mereka. Saya tidak tahu apa yang dilakukan perusahaan sehingga sulit untuk mengatakan mengapa ini tampaknya pilihan yang aneh. Anda dapat menggunakan komentar oleh @Daniel Pryden sehubungan dengan penggunaan perpustakaan pihak ketiga oleh Google.

Setiap perangkat lunak yang Anda gunakan, apakah itu internal atau dari pihak ketiga memiliki kelebihan dan kekurangan. Tidak menggunakan alat karena itu tidak di rumah, bahkan jika itu adalah alat terbaik untuk pekerjaan itu menunjukkan pola pikir tertutup tertentu dan itu tidak akan mendorong inovasi dan kreativitas.

Mungkin meskipun, mungkin saja, kaulah yang memperkenalkan perubahan itu. Semoga beruntung dengan semuanya.

Tentu saja kamu harus pergi. Saya belum melihatnya disebutkan di sini, tetapi alasan terbesar untuk melewati pekerjaan itu adalah karena Anda tidak akan mendapatkan banyak keterampilan yang dapat ditransfer.

Bayangkan pada wawancara Anda berikutnya ketika mereka bertanya teknologi apa yang bekerja dengan Anda dan Anda hanya bisa menyebutkan tulang kosong C ++ .. Kedengarannya seperti tingkat pascasarjana

Perusahaan besar menulis semuanya sendiri.

Ada beberapa keuntungan dalam menulisnya sendiri:

1. Anda dijamin memiliki perangkat lunak sendiri
2. Anda dapat menghitung jumlah pekerjaan yang benar untuk membuatnya
3. Mengulangi langkah Anda menjadi mungkin bahkan jika lib lain kali tidak tersedia
4. Ini mengurangi kebutuhan Anda mengasapi
5. Anda tidak mengulangi apa yang sudah dilakukan orang lain
6. Anda dijamin memiliki cukup banyak orang untuk memeliharanya
7. Anda dapat memodifikasi setiap bagian dari perangkat lunak
8. Ukuran perangkat lunak dibatasi oleh jumlah sumber daya yang Anda miliki

Inilah cara masing-masing poin terputus jika Anda menggunakan perpustakaan seseorang elses:

1. Orang lain memiliki Lib
2. Anda tidak tahu berapa banyak upaya yang dilakukan untuk menciptakan lib
3. Versi produk Anda berikutnya tidak mungkin dibuat di platform baru karena lib yang sama tidak lagi tersedia
4. Kemampuan untuk mengimplementasikan persyaratan tergantung pada apakah lib menerapkannya tahun lalu
5. Orang lain juga menggunakan lib yang sama, mendapatkan batasan dan fitur yang sama
6. Karena Anda tidak membuat lib, Anda tidak memiliki cukup orang untuk memelihara semua perangkat lunak dalam produk Anda
7. Lib adalah binari, tidak dapat dimodifikasi. Bahkan jika sumber tersedia, Anda tidak memiliki cukup banyak orang untuk memodifikasi kode dalam jumlah besar itu.
8. Mempertahankan kode yang Anda buat + libs adalah upaya yang lebih besar dari perkiraan semula