Memilih tumpukan teknologi adalah salah satu dari sedikit keputusan teknis yang terpaksa diambil oleh pendiri non-teknis sejak dini, biasanya di bawah tekanan, biasanya berdasarkan siapa yang mereka pekerjakan terlebih dahulu dan memberi tahu mereka apa yang mereka sukai. Ini adalah proses yang buruk, karena pihak yang paling diuntungkan dari tumpukan yang eksotik dan mutakhir ini adalah pengembang yang membangunnya, bukan bisnis yang harus menjalankannya selama lima tahun ke depan.

Saya sudah cukup mewarisi situasi ini untuk mengetahui polanya. Seorang pendiri mempekerjakan seorang insinyur yang antusias, insinyur tersebut memilih kerangka kerja yang secara pribadi mereka sukai atau inginkan dalam resume mereka, dan delapan belas bulan kemudian sang pendiri tidak dapat mempekerjakan orang lain yang mengetahuinya, tidak dapat memperoleh opini kedua mengenai suatu bug, dan secara fungsional disandera oleh satu orang. Ini bukan cerita tentang pengembang yang buruk. Ini adalah kisah tentang keputusan yang tidak dapat dievaluasi dan didelegasikan sepenuhnya oleh sang pendiri.

Anda tidak perlu memahami manfaat teknis dari satu kerangka kerja dibandingkan kerangka lainnya untuk membuat keputusan yang baik di sini. Anda memerlukan tiga proxy yang dapat dinilai oleh pendiri mana pun tanpa menulis sebaris kode pun.

Anda tidak bisa menilai kerangka kerja, tetapi Anda bisa menilai proxy

Tidak ada yang mengharapkan seorang pendiri untuk memiliki pendapat tentang arsitektur internal kerangka web, dan jika seorang pengembang mencoba membuat Anda tertarik dengan keanggunan teknis pilihan mereka, itu adalah sinyal untuk memperlambat, bukan mempercepat.

Apa yang dapat Anda nilai dengan andal, tanpa latar belakang teknis:

  • Berapa banyak pengembang lokal yang mengetahuinya. Tanyakan pada perekrut, atau cukup periksa daftar pekerjaan di kota Anda. Jika hampir tidak ada orang di pasar perekrutan Anda yang mencantumkannya sebagai suatu keterampilan, Anda akan membayar mahal untuk setiap perekrutan, selamanya, dan Anda akan memiliki daftar orang yang sangat sedikit untuk dihubungi ketika ada masalah.
  • Seberapa tua dan membosankan kerangka kerja tersebut. Kerangka kerja yang telah stabil selama lebih dari lima tahun memiliki bug terburuk yang ditemukan dan diperbaiki dengan uang orang lain, bukan uang Anda. Kebaruan adalah biaya yang Anda bayar, bukan fitur yang Anda dapatkan.
  • Siapa lagi yang menjalankannya pada skala yang mendekati skala Anda. Bukan contoh yang cemerlang. Bisnis kira-kira seukuran Anda, di industri Anda atau yang berdekatan, dengan tenang menjalankan bisnis yang sama selama bertahun-tahun tanpa drama. Kisah sukses yang membosankan, bukan studi kasus pembicaraan konferensi.

Jika tumpukan yang diusulkan gagal ketiganya, itu belum tentu salah, namun itu berarti Anda mengambil risiko teknis yang setidaknya harus diberitahukan secara eksplisit, bukan risiko yang terkubur di dalam "kami menggunakan praktik terbaik modern".

Jebakan satu pengembang

Satu-satunya kesalahan paling mahal yang saya lihat adalah seorang pendiri memberi lampu hijau pada tumpukan yang dipilih oleh salah satu pengembang yang antusias tanpa bertanya siapa lagi yang dapat mengambil ini jika orang tersebut berangkat besok. Rasanya tidak perlu menanyakan hal ini di bulan pertama, ketika hubungannya sangat baik dan pengembangnya jelas berbakat. Ini menjadi satu-satunya pertanyaan yang penting di bulan kedelapan belas, ketika pengembang tersebut mendapat tawaran yang lebih baik dan membawa satu-satunya pengetahuan kerja sistem Anda bersama mereka.

Hal ini terkait langsung dengan pilihan antara build vs buy: tumpukan kustom eksotis yang dibuat oleh satu orang secara efektif merupakan keputusan "build" yang tidak Anda sadari telah Anda buat, dengan semua risiko pemeliharaan sistem yang dipesan lebih dahulu dan tidak ada dukungan vendor yang akan diberikan oleh produk yang dibeli kepada Anda.Tanyakan, sebelum keputusan apa pun diselesaikan: "Jika orang ini pergi dalam enam bulan, seberapa sulitnya menemukan penggantinya, dan berapa lama waktu yang dibutuhkan mereka untuk menjadi produktif?" Jika jawaban jujurnya adalah "sangat sulit" dan "waktu yang lama", Anda memerlukan alasan yang sangat kuat untuk menerima risiko tersebut, bukan sekadar antusiasme.

Pertanyaan yang melindungi Anda

Jalankan ini sebelum menandatangani keputusan tumpukan apa pun, milik Anda atau kontraktor:

  1. Apakah tumpukan ini digunakan oleh perusahaan seukuran kami, melakukan hal yang kira-kira sama dengan yang kami lakukan? Bukan arsitektur referensi berskala FAANG. Skala Anda.
  2. Berapa banyak pengembang di pasar perekrutan kita (atau pasar ramah jarak jauh) yang sudah mengetahui hal ini? Tanyakan kepada perekrut mengenai angka sebenarnya, bukan tebakan.
  3. Apa yang terjadi jika pengembang saat ini keluar? Dapatkan jawaban spesifik, bukan kepastian.
  4. Apakah ada alternatif lama dan membosankan yang melakukan 90% pekerjaan yang sama? Jika ya, apa alasan sebenarnya kami tidak menggunakannya?
  5. Siapa vendor atau komunitas yang menjaga kelangsungan proyek ini, dan apakah mereka masih aktif mempertahankannya dua tahun dari sekarang? Periksa aktivitas proyek yang sebenarnya, bukan pemasarannya.

Semua ini tidak mengharuskan Anda memahami kode. Semuanya mengharuskan Anda untuk bersikeras pada jawaban yang sebenarnya daripada menerima "percayalah".

Membosankan adalah strategi bisnis, bukan kompromi

Para pendiri terkadang khawatir bahwa memilih tumpukan yang lebih tua dan lebih umum menandakan kurangnya ambisi atau kecanggihan teknis. Sebaliknya. Bisnis yang berskala baik memperlakukan tumpukan teknologi mereka dengan cara yang sama seperti mereka memperlakukan perangkat lunak akuntansi mereka: dapat diandalkan, dapat dipahami dengan baik, dapat diganti jika diperlukan, dan tidak terlihat saat berfungsi. [Biaya tersembunyi dari sistem lama] (/blog/hidden-cost-of-legacy-systems) memang nyata, tetapi itu adalah kegagalan yang berbeda, sistem yang tidak pernah dipelihara, bukan sistem yang tidak menarik saat dipilih.

Bisnis yang pernah saya lihat mengalami kegagalan memilih kegembiraan dibandingkan keandalan pada lapisan dasar dan membayarnya dengan kesulitan perekrutan, risiko faktor bus, dan perbaikan bug yang lambat selama bertahun-tahun setelahnya. Bisnis yang berkembang dengan lancar membuat pilihan yang membosankan sejak awal dan menghabiskan energi inovasi mereka yang sebenarnya pada produk, bukan pada pipa ledeng.

Kesimpulannya

Anda tidak akan pernah bisa menilai suatu kerangka kerja berdasarkan kemampuan teknisnya, dan itu tidak masalah, itu bukan tugas Anda. Apa tugas Anda adalah menanyakan apakah bisnis lain seperti milik Anda berhasil menjalankan tumpukan ini, apakah Anda dapat mempekerjakannya secara lokal, dan apa yang terjadi pada hari pengembang Anda saat ini keluar. Dapatkan jawaban yang jujur ​​terhadap ketiga pertanyaan tersebut sebelum keputusan apa pun menjadi kaku, dan jika Anda menginginkan opini kedua mengenai proposal yang sudah ada di meja Anda, percakapan seperti itulah yang layak dilakukan di /partner.