Bagaimana manajer memilih bahasa pemrograman

Bukan rahasia bagi siapa pun bahwa manajer dapat dan sering akan memaksakan bahasa pemrograman yang akan digunakan untuk proyek.

Menjadi seorang programmer sendiri, saya tidak pernah bisa memahami ini.

Tapi sekarang saya rasa saya lakukan: Saya baru saja mendapat wahyu ketika Joel Spolsky mengatakan di podcast bahwa mereka harus menggunakan QuickBooks karena "setiap akuntan di dunia tahu itu". Ini menurut saya sangat mirip dengan "memilih Java karena setiap programmer di dunia tahu itu".

Sekarang saya telah melihat masalah yang sama dari perspektif lain, saya tidak tahu banyak tentang akuntansi, tetapi saya tahu sesuatu tentang pemrograman, saya bertanya-tanya bagaimana seorang programmer dapat membantu memastikan bahasa pemrograman yang tepat dipilih untuk suatu proyek ?

Kesalahan yang dibuat oleh banyak programmer adalah mereka akan memperdebatkan poin (atau hanya setuju atau tidak setuju dengan itu) hanya berdasarkan pada kemampuan teknis. Dengan manajemen - dan bisnis secara keseluruhan - Anda harus memperdebatkan kasus bisnis dan manfaat untuk bisnis terlebih dahulu dan keunggulan teknis kedua.

Ini melampaui pilihan bahasa pemrograman dan mencakup hampir setiap keputusan teknis.

Biarkan saya memberi Anda sebuah contoh: PC. Joel berpendapat (dengan benar) bahwa pengembang harus memiliki mesin kelas satu karena waktu pengembang mahal. Dalam hal ini dia sepenuhnya benar. Tetapi bagaimana Anda memperdebatkan hal ini? Sederhana:

Contoh: Saya membuat kode kira-kira 20 kali sehari. Setiap kali dibutuhkan 3 menit. Jika saya punya PC cepat saya bisa membuatnya dalam 1,5 menit. Jadi untuk tambahan $ 1.000 setiap dua tahun saya bisa mendapatkan setengah jam ekstra sehari, yang bagi seorang programmer menghasilkan $ 100rb (dengan on-biaya setidaknya 50% lainnya), yang setara dengan sekitar $ 10.000 per tahun waktu.

Tetapi berargumen di ujung yang lain adalah HR yang memutuskan satu ukuran cocok untuk semua ketika menyangkut kebijakan dan PC sehingga pekerja call center menghasilkan $ 25k dan seorang programmer mendapatkan empat kali lipat yang karena alasan tertentu memiliki PC yang sama.

Platform teknologi dan bahasa akan memiliki banyak faktor yang masuk ke dalam bauran keputusan:

• Hubungan strategis dengan vendor tertentu. Jika perusahaan Anda adalah Microsoft Gold Partner (atau apa pun namanya sekarang), semoga sukses memasukkan Java atau Python;
• Departemen TI memperdebatkan konfigurasi tertentu karena uang untuk PC keluar dari anggaran mereka;
• TI yang memutuskan semua orang harus menjalankan Windows 2000 karena mereka tidak memiliki orang yang menjalankan Linux;
• Apa sistem lain yang sudah dimiliki perusahaan (mis. Jika mereka menggunakan Java untuk semua hal lain, masuk akal untuk menggunakannya untuk ini walaupun dengan sendirinya itu mungkin bukan pilihan terbaik);
• Keengganan terhadap berbagai platform atau bahasa hanya karena kurangnya pengalaman;
• Lebih tertarik berdebat risiko dengan manajemen atas daripada membuat pengembang senang;
• Beberapa manajer membuat keputusan yang mereka lakukan hanya karena tangan mereka terikat;
• Alasan anggaran meskipun ini dapat menguntungkan Anda juga karena menjaga kacamata mahal keluar dari rumah Anda seperti PVC, apa pun yang diproduksi oleh Rasional, dll;
• Keengganan departemen hukum terhadap lisensi sumber terbuka;
• Tidak melibatkan staf teknis dalam perencanaan dan estimasi proyek;
• Keakraban pada bagian manajer dengan platform tertentu (orang-orang teknis juga bersalah atas hal ini tetapi dalam kedua kasus itu tidak selalu merupakan hal yang buruk - dengan banyak alat yang dapat melakukan pekerjaan dengan lebih baik iblis yang Anda tahu).
• Pengalaman staf teknis. Jika mereka semua dari latar belakang C #, mengapa mereka menggunakan Java, Python atau Ruby?
• Banyak alasan lainnya

Apapun masalahnya Anda perlu memahami alasannya (dan saya jamin Anda akan ada beberapa alasan) dan berdebat manfaat dalam istilah itu. Beberapa programmer cukup naif dalam departemen ini dan tampaknya berpikir bahwa keputusan seperti itu dibuat karena ketidaktahuan atau bahkan pembalasan ketika hampir selalu ada banyak faktor yang berperan.

Dari apa yang tampak di perusahaan saya: Ketika manajer memilih bahasa pemrograman, mereka biasanya melakukannya dengan sangat konservatif - dengan mempertimbangkan keterampilan pemrograman seperti apa yang saat ini tersedia dalam tim (dan jika mudah untuk merekrut yang lain dengan mudah ), apakah itu bahasa yang mapan, mencoba memilih sesuatu yang sesuai dengan infrastruktur saat ini dan tidak menyebabkan upaya besar untuk membuatnya sesuai dengan apa yang sudah ada. Ketika programmer memilih bahasa pemrograman, hal-hal sering cenderung sedikit berbeda - mereka sering suka memiliki tantangan baru dan ingin mendapatkan dengan tren panas terbaru dan memilih sesuatu di mana mereka dapat mempelajari hal-hal baru.

Idealnya, semuanya bermula untuk membahas pro dan kontra antara manajer dan tim pengembang dan menemukan solusi yang paling sesuai dengan masalah tersebut. Ini biasanya melibatkan banyak bicara dan meyakinkan :-)

Terlambat membalas, tetapi karena belum ada jawaban yang diterima, saya akan mencobanya. Saya menganggapnya sebagai dua pertanyaan dan akan berusaha menjawabnya secara terpisah:

Bagaimana manajer memilih bahasa pemrograman?

Sangat tergantung pada ukuran pengalaman organisasi dan manajer, tetapi umumnya akan melibatkan penilaian situasi saat ini dan skenario masa depan dan persyaratan. Ini biasanya dilakukan melalui PESTLE atau analisis serupa, dan hanya untuk memberikan beberapa sampel di setiap kategori:

• Politik
  • "Tidak ada yang dipecat karena membeli IBM" - pilihan yang aman.
  • CEO mendengar bahwa Java keren - hype.
  • Chief Architect menyukai proyek .NET - pet.
  • Bahasa ini dikendalikan oleh pesaing yang bermusuhan - mengapa Google tidak mengandalkan C #.
• Ekonomis
  • Biaya lisensi.
  • Biaya pelatihan pengembang.
  • Biaya migrasi basis kode.
• Sosial
  • Beli dari tim.
  • Ketersediaan keterampilan di rumah (kebutuhan pelatihan, kontinuitas).
  • Ketersediaan keterampilan di pasar.
  • Ancaman terhadap status quo yang ada dalam tim dev.
  • Ketersediaan komunitas praktik yang cukup besar.
• Teknologi
  • Peningkatan produktivitas.
  • Perbaikan mutu.
  • Kemampuan untuk beroperasi dengan basis kode yang ada.
  • Kepatuhan terhadap standar.
  • Kematangan.
• Hukum
  • Ketentuan lisensi.
  • Kontrol teknologi (Siapa yang memiliki dan mengendalikan teknologi? Bagaimana strategi perizinan di masa depan?)
  • Kepatuhan hukum dan peraturan.
• Lingkungan
  • Infrastruktur yang ada dalam perusahaan.
  • Keterampilan yang ada dalam perusahaan.
  • Integrasi dengan mitra eksternal.
  • Tingkat dukungan teknologi oleh lingkungan yang lebih luas.

Kemudian sekelompok bahasa yang cocok dengan kriteria dapat dievaluasi lebih lanjut menggunakan SWOT , analisis manfaat biaya atau sejenisnya.

Seluruh proses bisa agak rumit, tetapi sebagai garis bawah sebagian besar perusahaan atau tim proyek akan memilih opsi teraman mengingat keadaan mereka saat ini yang masih dapat memberikan kemampuan yang mereka butuhkan. Cukup sering itu mungkin berarti tetap pada platform saat ini lebih lama.

Bagaimana seorang programmer dapat membantu memastikan bahasa pemrograman yang tepat dipilih untuk suatu proyek

Seperti yang telah, semoga, menunjukkan programmer khas biasanya hanya memiliki 1/6 dari total input ke dalam proses pengambilan keputusan. Dan sebagai aturan dia atau dia sebagian besar akan tertarik pada kemampuan bahasa saja!

Nah, cara terbaik untuk mempengaruhi keputusan tampaknya memiliki gambaran yang lebih luas tentang proses seleksi, membuat sekutu di dalam dan di luar tim, membuat brief yang bagus di sisi teknologi dan mencoba untuk tidak berkonsentrasi pada kemampuan bahasa saja.

Dan, tentu saja, seseorang perlu masuk ke posisi ketika seorang Manajer Proyek atau Pengembangan (atau siapa pun yang bertanggung jawab) melihat manfaat melalui seluruh proses evaluasi dan siap untuk mempertimbangkan risiko dan ketidakpastian beralih ke yang berbeda. bahasa di tempat pertama. Agar hal ini terjadi, perlu ditunjukkan bahwa:

1. Platform saat ini tidak lagi memadai.
2. Sebuah platform baru menjanjikan manfaat yang jauh melebihi kerumitan.

Namun, akankah Anda bertanya "Apa cara terbaik untuk dapat menggunakan bahasa yang saya suka di tempat kerja", jawabannya mungkin "bergabung dengan perusahaan yang sudah menggunakan bahasa itu atau mulai bahasa Anda sendiri".

Manajer A pergi ke retret musim panas di mana ia bertemu manajer B.

A: Jadi bahasa apa yang Anda gunakan di perusahaan Anda? B: Oh, kami menggunakan CA Visual Objects, itu membuat drone jauh lebih produktif daripada COBOL.

Dan inilah bagaimana keputusan itu dibuat. Akhir dari kisah nyata.

Setiap platform memiliki sisi baik dan buruk. .NET keren dan kuat tetapi Anda cukup banyak terjebak dengan server Windows. Ruby itu keren tapi lambat. Akan sulit untuk menemukan pengembang untuk Haskell.

Intinya adalah, bahasa mempengaruhi bukan seberapa cepat proyek akan dilakukan dan seberapa indah kode akan tetapi juga hal-hal yang diperhatikan oleh manajer. Jadi, jika Anda ingin memengaruhi mereka, Anda sekarang harus memilih dan menemukan sebanyak mungkin sisi baik dalam perspektif mereka.

Dengan memisahkan masalah. Bisnis harus bertanggung jawab atas keputusan bisnis dan teknisi yang bertanggung jawab atas keputusan teknologi. Saya suka istilah "Tanggung jawab yang diterima". Jika saya menerima tanggung jawab, saya juga menuntut agar saya membuat pilihan yang menyangkut domain masalah saya. Bisnis memberi saya dan kolega teknologi saya tuntutan bisnis dan kami menjawab dengan satu atau dua alternatif tentang bagaimana kami dapat menerima tanggung jawab untuk diberikan. Seharusnya tidak seperti "kita akan melakukannya dengan Python atau C #". Agak;

"Kami dapat menerima dua tanggung jawab yang berbeda di sini: Jika kami pergi dengan cara ini, kami dapat memberikan ini dengan cepat dan kami memenuhi tuntutan bisnis ini dengan sangat baik dan ini sedikit lebih sulit. Kami juga dapat melakukannya dengan cara ini dan yang memberikan tuntutan bisnis ini pada truf Alternatif A menyerukan sumber daya ini dan alternatif B berarti kita juga perlu melakukan ini dan ini ... "

Kemudian bisnis memilih, tetapi perhatikan bahwa bisnis memilih berdasarkan dampak pada hal bisnis, bukan hal teknis. Dan mereka tidak bisa memilih di antara alternatif di mana teknologi tidak siap untuk menerima tanggung jawab dari bagian teknologi.

Menjadi manajer. (menyeringai)

Serius, Anda hanya perlu mendiskusikan masalah ini dengan pembuat keputusan yang bersangkutan, dan mengemukakan argumen Anda. Jika mereka memilih untuk tetap dengan keputusan yang benar - benar salah, maka kompetensi umum mereka mungkin tidak begitu panas dan mungkin ada baiknya mencari hal lain untuk dilakukan.

Saya pikir perbedaan antara apa yang Anda bicarakan dan apa yang Joel bicarakan adalah bahwa pemrograman adalah kompetensi inti sedangkan akuntansi tidak. Poin menggunakan Quickbooks, mungkin, karena Anda bukan seorang akuntan dan akuntan dapat membantu Anda. Namun, jika pemrograman adalah kompetensi inti Anda, dan mungkin itu adalah jika Anda seorang programmer, maka aturan mainnya sedikit berbeda.

Itu sangat tergantung pada kepribadian manajer:

Ada yang menggunakan kata kunci. Cari tahu buzzword mana yang mereka sukai dan gunakan ketika Anda berbicara dengannya bersamaan dengan bahasa yang ingin Anda gunakan.

Orang lain hanya akan mempercayai hal-hal yang mereka ketahui sendiri (seperti VB 6.0 misalnya). Jadikan bahasa pilihan Anda mudah dimengerti bagi mereka ('Anda tahu, itu seperti VB tua yang baik' - bahkan jika Anda berbicara tentang Haskell ...)

Namun dalam kenyataannya, sebagian besar manajer tidak sebodoh yang kita pikirkan, dan mereka dapat beralasan. Yang penting di sini adalah Anda memahami sudut pandang mereka: Mereka biasanya tidak peduli dengan detail teknis tertentu, mereka peduli pada hasil. Jadi jangan beri tahu mereka bahwa .net atau Java atau Delphi atau apa pun yang memiliki fitur hebat megacool ini. Beri tahu mereka bahwa (masukkan bahasa Anda di sini) adalah pilihan yang baik karena fitur A membuat waktu pengembangan yang lebih singkat dalam proyek seperti ini, atau fitur itu B membuat lebih sedikit bug dan karenanya mempersingkat waktu yang diperlukan untuk pengujian. Pastikan argumen Anda masuk akal, jangan bohongi dia.

Dengan kata lain: perlakukan dia seperti makhluk inteligen (mungkin dia).

Pikirkan tentang bahasa yang diminta untuk Anda gunakan dengan sangat keras. Pastikan Anda tahu bahwa itu bukan bahasa yang baik untuk pekerjaan itu, kemudian tanyakan kepada manajer apakah Anda dapat memberi saran tentang bahasa lain yang lebih baik untuk digunakan untuk pekerjaan itu. Berikan informasi yang Anda bisa yang membuktikan bahwa bahasa tersebut tidak baik untuk pekerjaan itu dan lihat apa yang ia katakan. Tidak ada salahnya. :)

Memilih bahasa pemrograman seringkali merupakan keputusan bisnis. Pelanggan / Pengguna tidak peduli. Berikut ini kutipan singkat (dari http://www.ericsink.com/bos/Geeks_Rule.html ):

Bahasa pemrograman dipilih terutama untuk alasan bisnis. Saya menghabiskan sebagian besar waktu saya bekerja dengan bahasa-bahasa yang tidak saya sukai karena bahasa-bahasa yang ingin saya pakai membawa kerugian bisnis yang lebih besar daripada kelebihan teknisnya. Itulah sifat permainannya. Saya dapat menerima situasi (pilihan saya) atau mencari majikan baru. Merengek tentang bagaimana saya tidak bisa menggunakan Java atau Python atau apa pun di tempat kerja bukan merupakan pilihan.

Pertama-tama, pemrograman adalah bentuk seni lainnya. Suatu bentuk seni yang sangat logis. Jika manajer Anda tertarik pada proyek perangkat lunaknya yang luar biasa, yang sampai batas tertentu, karya mahakarya, maka tanyakan kepada manajer yang tajam berikut:

Berapa banyak energi dan waktu yang dibutuhkan Rembrandt ekstra untuk tidak melukis dengan kuas favoritnya, tetapi kuas yang, setelah pertimbangan tim manajemen, diberikan kepadanya, 400 tahun yang lalu dan sebelum karyanya menjadi terkenal. Apakah lukisannya akan lebih atau kurang layak menurut Anda?

Demikian pula, Jika Anda memberi tahu seorang programmer bahasa apa yang harus digunakan, maka konsistenlah dan beri tahu seorang pelukis ukuran kuas apa yang harus digunakan! ATAU, sebagai alternatif, serahkan saja pilihan ini kepada orang-orang yang perlu bekerja dengannya setiap hari dan (seperti kebanyakan karya agung) malam!

Ini adalah konsep yang berbeda.

Saat menghitung, Anda membagikan hasilnya: untuk pajak, hukum, investor, dll. Mereka membutuhkan alat untuk melihat hasil kerja Anda, dan alat ini harus diketahui dengan baik.

Saat memprogram, Anda menggunakan alat apa pun yang Anda inginkan - asalkan menghasilkan .exefile yang dapat Anda jalankan di Windows. Ini persis sama dengan dokumen yang dapat dibaca Buku Cepat dalam hal akuntansi.

Jadi, jika Anda mengembangkan pemanggang roti, Anda bebas untuk menyimpan dokumentasi internal Anda dalam bahasa Cina tetapi Anda sebaiknya memberikan manual bahasa Inggris.

Ada satu hal lagi: jika aturan perusahaan Anda mengasumsikan bahwa hasil kode Anda bukan produk itu sendiri, tetapi kode sumber untuk itu, maka pasti mereka dapat memutuskan seperti apa bentuknya (dengan memilih bahasa yang mereka inginkan).

Apa yang mereka pilih tergantung pada tujuan mereka: jika mereka ingin programmer yang mudah diganti mereka memilih Java; jika mereka mengirimnya ke departemen lain, itu akan menjadi persyaratan departemen itu dll.

Dalam pengalaman saya itu selalu tergantung pada:

1. Apakah kita memiliki sumber daya untuk menggunakan bahasa itu?
2. Apakah kita memiliki sumber daya untuk mempertahankan bahasa?
3. Jika kita tidak memiliki sumber daya untuk menggunakan dan memelihara bahasa, seberapa sulit / mahalkah untuk mendapatkan sumber daya itu?
4. Apa "masa depan" bahasa (Apakah akan ada dan digunakan untuk sementara waktu?)

Kecuali jika proyek membutuhkan sesuatu yang hanya menggunakan bahasa / platform / teknologi / kerangka kerja tertentu, hal itu bergantung pada apa yang sudah kita ketahui dan gunakan. Baik mempekerjakan orang baru dan melatih programmer yang ada cukup mahal untuk sebagian besar perusahaan. Saat merekrut, kami selalu mempertimbangkan bahasa dan memastikan kandidat tahu bahasa apa yang mungkin akan mereka gunakan.

Semoga Anda memiliki seorang programmer yang juga seorang manajer dan yang dapat mewakili programmer dalam jenis keputusan ini. Jika tidak maka itu adalah situasi berbahaya dan Anda harus berbicara dengan manajer Anda jika Anda tahu keputusan seperti itu sedang dibuat.