Seberapa umumkah sebuah tim menulis semuanya sendiri? [Tutup]


53

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?


58
Bendera merah besar. Pergi dengan tenang dan jangan bergerak tiba-tiba.
tdammers

16
Saya tidak berpikir ini konyol seperti yang dikatakan orang ... Baru-baru ini saya menyia-nyiakan banyak waktu untuk memperbaiki perpustakaan yang ditinggalkan untuk versi kerangka kerja baru, versi baru perpustakaan dengan perubahan besar yang tidak didokumentasikan dan bahkan kesenjangan yang sangat besar dalam kerangka kerja yang signifikan seperti jQuery yang membuatnya tidak cocok untuk tujuan. Orang tidak berusaha cukup keras untuk memutuskan apakah komponen bagian ketiga akan menambah overhead pemeliharaan yang besar dan sering berakhir dengan tombak neraka ketergantungan spageti yang tidak dapat dipelihara.
Danny Tuppeny

4
NuGet luar biasa, tetapi membuatnya sangat mudah untuk melakukan ini. Saya memasang beberapa perpustakaan pembantu sepele dari NuGet baru-baru ini, dan menarik Kastil dan segala macam omong kosong lainnya. Tentu; larangan langsung itu aneh, tapi itu tidak lebih bodoh daripada membiarkan setiap dev dan anjingnya menarik barang-barang secara acak tanpa pikiran sungguhan.
Danny Tuppeny

13
Segala sesuatu? Apakah itu termasuk browser mereka sendiri, sistem operasi dan kompiler? Kalau tidak, mereka hanya menipu diri sendiri.
Muhammad Alkarouri

4
Tentu saja konyol seperti yang dikatakan orang. Fakta bahwa a) dimungkinkan untuk memilih perpustakaan yang salah untuk pekerjaan itu dan b) ada situasi di mana tidak ada perpustakaan pihak ketiga yang memenuhi kebutuhan Anda lebih baik daripada yang ada di rumah: tidak berarti bahwa kebijakan menyeluruh untuk tidak pernah menggunakan pihak ketiga perpustakaan sudah benar.
user16764

Jawaban:


76

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.

1
+1 tetapi saya pikir yang Anda maksud adalah sektor swasta , bukan sektor publik .
MarkJ

6
"Jika kodenya adalah open source, maka dalam kasus terburuk, perpustakaan pihak ketiga menjadi tidak terawat. Tapi siapa yang peduli? Tes membuktikan bahwa perpustakaan itu sesuai dengan kebutuhan Anda!" Anda juga memiliki kode sumber, yang menempatkan Anda pada posisi memiliki apa yang Anda gunakan sekarang dan dapat memperbaruinya untuk memenuhi kebutuhan masa depan. (Ya, membiasakan diri dengan basis kode "alien" membutuhkan waktu, tetapi demikian juga bergulir sendiri.)
CVn

34

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.


2
Karena pengembang tidak lagi memiliki keterampilan yang relevan untuk pekerjaan lain, uang perusahaan yang hilang karena waktu pengembangan yang lama diselamatkan dengan tidak harus mengganti anggota tim yang pergi! #stratgey
Michael Paulukonis

@Michael: Satu-satunya orang yang bisa mereka pertahankan adalah orang-orang yang hadir untuk keputusan awal untuk membuat kerangka kerja internal. Karyawan baru cenderung pergi setelah sekitar satu tahun.
kevin cline

</itwasaweakjoke>
Michael Paulukonis

+1 Jika fitur yang hilang benar-benar, sangat, penting: ubah perpustakaan open-source dan kontribusikan fitur tersebut ke sumber utama. Memberikan nilai bisnis yang hebat, membuat semua orang merasa baik dan itu sangat baik untuk CV semua orang karena mereka sekarang telah memberikan kontribusi open-source.
MarkJ

@ MarkJ: tetapi jika perubahan ditolak, seseorang akan memiliki ego yang memar.
kevin cline

20

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.


15

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!)


11

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.


+1 salah satu alasan utama saya pindah dari perusahaan saya sebelumnya!
Antony Scott

5

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.


4

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.


4

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.


1

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.


-3

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


"Saya belum melihatnya disebutkan di sini" - apakah Anda melihat jawaban lain, misalnya yang ini ?
nyamuk

3
Tidak akan mendapatkan banyak keterampilan? Itu konyol. Itu hanya benar jika Anda melihat pemrograman sebagai bermain dengan blok Lego, menumpuk komponen bersama-sama. Jika Anda harus 'menciptakan kembali' perpustakaan, Anda akan belajar banyak tentang topik tertentu.
GrandmasterB

@ GrandmasterB Anda benar, izinkan saya mengklarifikasi - Banyak tempat bertanya alat apa yang Anda gunakan. Peluang Anda untuk diabaikan jauh lebih tinggi jika kandidat lain dapat mulai berjalan sementara Anda harus belajar dari awal.
Martin Konecny

-9

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

7
Bukankah ekstensi logis dari argumen-argumen ini juga untuk menulis kompiler Anda sendiri (mungkin untuk bahasa Anda sendiri), menjalankan perangkat lunak ini pada OS Anda sendiri, dan mungkin membangun HW Anda sendiri juga?
timday

4
1: Ya dan saya dapat membayar biaya untuk menggunakannya (tanpa mengeluarkan uang untuk membuat perbedaan biaya). 2: Jika saya tidak membangunnya, saya tidak peduli. 3: Dalam platform bisnis lambat untuk berubah. Tetap terdepan jarang merupakan persyaratan. Tetapi perangkat lunak yang bagus mudah dipindahkan. 4: Tidak benar. Anda cukup mentransfer bloat dari eksternal ke internal. 5: Tidak masuk akal. 6: Tidak benar. 7: Benar tetapi berarti Anda perlu mengalihkan programmer berharga Anda (bagian paling mahal dari suatu proyek) dari pekerjaan nyata menjadi perbaikan bug pada sesuatu yang dapat dipertahankan di tempat lain. 8: Itu hal yang buruk.
Martin York

5
Banyak perusahaan besar menggunakan kode sumber terbuka secara luas dalam berbagai bentuk (termasuk lib), sering kali meningkatkan / berkontribusi pada proyek-proyek terkait. Poin-poinnya sebagian besar tidak relevan atau salah.
Matt

7
@ tp1: Saya bekerja untuk Google dan saya dapat meyakinkan Anda bahwa Google sangat menggunakan perpustakaan pihak ketiga ketika mereka memenuhi kebutuhan kami. Banyak kali Google memiliki kebutuhan yang unik atau pada skala yang berbeda dari banyak perusahaan perangkat lunak lain, jadi karena satu dan lain alasan Google akan sering mengembangkan berbagai hal di rumah. Tetapi Google juga menggunakan sejumlah besar perpustakaan open-source, dan / atau open-source banyak perpustakaan internal, jadi tidak semuanya ada di rumah. Sebagian besar poin Anda tidak lagi berlaku untuk perangkat lunak sumber terbuka, karena dengan memiliki sumber Anda memastikan bahwa Anda selalu dapat men-debug dan memperbaikinya jika perlu.
Daniel Pryden

5
"Tidak, nilai berasal dari penerapan persyaratan secara akurat. Jika dibangun sebelum persyaratan diketahui, nilai tersebut tidak dapat secara akurat menerapkan persyaratan yang tepat itu." Petunjuk: Jika Anda berpikir argumen ini memiliki manfaat sama sekali, maka Anda telah gagal memahami pemisahan kekhawatiran.
user16764
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.