Perkembangan model pembuatan aplikasi semakin meriah akhir-akhir ini. Hanya dalam hitungan bulan, beragam tech stack baru bermunculan -- dengan akronim nya masing-masing. Tech stack menggabungkan berbagai lini dalam pembuatan aplikasi -- mulai dari bahasa pemrograman, sistem deployment, sampai manajemen data. Di tengah membanjirnya tech stack baru timbul skeptisme: perlukah para dev yang sudah berkecimpung di suatu tech stack untuk segera beradaptasi dengan tech stack baru? Benarkah alasan bahwa bertahan pada suatu tech stack akan tertinggal kemajuan? Baca sampai selesai beberapa fakta menarik berikut ini!
Fun Fact #1: Client tidak perduli dengan tech stack yang digunakan pada aplikasi yang dibutuhkannya
Fakta menarik ini cukup mencengangkan bukan? Pada dasarnya client mengabaikan detil teknis aplikasi yang dibutuhkannya. Mereka menurut saja, namun memiliki emphasis (penekanan). Untuk client di bidang keuangan, emphasis pada keamanan dan kecepatan. Untuk client di bidang commerce, emphasis pada kemampuan handling request massal secara real time. Client bidang lain emphasis pada total cost of ownership yang terjangkau. Sebuah quote menarik untuk disimak:
there is no technology fits all client needs
Tim development yang baik harus memerhatikan emphasis ini. Pemilihan tech stack tinggal menyesuaikan emphasis dan tentu saja ketersediaan budget. Jangan sampai terjadi over budget malah mendapatkan tech stack yang tidak memenuhi target emphasis. Atau sebaliknya, budget mepet dipaksa memakai tech stack terkini dengan fitur yang sebenarnya di luar emphasis client.
Fun Fact #2: Jumlah penduduk bumi sekitar 8 milyar dan semua nya butuh makan
Mungkin fakta menarik ini menimbulkan pertanyaan: "apakah saya harus ikut memikirkan kebutuhan makan semua penduduk bumi?". Dalam kaitan dengan perkembangan tech stack, jika kita perhatikan alasan terkuat seseorang berusaha menguasai segala macam tech stack adalah takut tidak kebagian job yang menggunakan tech stack yang belum dikuasainya. Pada dasarnya alasan ini bisa dibilang mengada-ada. Betul, ada sebagian software house yang menentukan tech stack terlalu dini, bahkan sebelum mengetahui real kebutuhan client dan merekrut dev baru. Namun hal tersebut tetap saja tidak dapat dijadikan landasan agar setiap dev mengantisipasi segala kemungkinan.
Seandainya dalam kondisi tertentu tim dev terpaksa memakai lebih dari 1 macam tech stack, maka sikap bijaksana yang dapat diambil adalah dengan collab -- memecah project sesuai dengan tech stack yang dikuasai anggota tim dev.
Dalam setiap keputusan tim dev selalu ada trade off (harga):
- jika memaksa dev untuk bekerja dengan tech stack yang tidak dikuasai maka akan memperlambat proses development karena dev lebih banyak beradaptasi ketimbang mengembangkan fitur yang dibutuhkan client
- jika merekrut dev serba bisa maka akan menurunkan performa dev ybs sebab fokus nya bercabang cabang
- jika melakukan collab untuk menyesuaikan skill dev terhadap tech stack yang digunakan maka akan menambah biaya pembuatan aplikasi
- jika melibatkan AI maka selain ada penambahan biaya untuk sewa AI -- yang hanya berguna saat development -- maka timeline akan makin panjang khususnya untuk melakukan code check yang dihasilkan AI guna memastikan kesesuaian dengan fitur yang dibutuhkan client
Dari trade off tersebut, yang paling bijaksana dan realistis tetaplah melakukan collab. Tentu saja, poin terpenting dari collab adalah memberikan kesempatan bagi dev baru untuk meraih pendapatan yang diharapkan dapat membantu mengurangi pengangguran.
Fun Fact #3: Project yang dikerjakan oleh banyak dev cenderung lebih stabil
Fakta menarik ini tak kalah mencengangkan bukan? Mungkin banyak yang merasa heran -- khusus nya para dev serba bisa dan single fighter -- kok bisa?
Tentu saja! Sebab project yang dikerjakan oleh banyak dev itu memiliki bagian-bagian yang terpisah. Jika satu bagian mengalami crash, bagian lain tetap normal. Dengan begitu test juga bisa dilakukan bertahap, bagian per bagian. Tak hanya itu, deployment pun bisa dilakukan bertahap pula, bagian per bagian. Selain itu semakin banyak dev yang terlibat, semakin banyak pula kepala yang ikut memikirkan solusi atas permasalahan, bug fixing, serta patch. Dengan sendirinya, project tersebut semakin stabil per rilis. Quite simple!
Berkaca dari project-project open source besar, terlihat bahwa project tersebut memiliki sekian ratus contributor yang bekerja di bagian yang berbeda-beda. Hal ini terlihat dari antrian pull request di repo project tsb. Dan hasilnya bisa kita lihat, project tersebut bisa rilis stable version secara rutin.
Namun dibalik luar biasanya para contributor, ada skeptisme: apa yang terjadi jika ada dev yang tiba-tiba meninggalkan bagian nya yang belum selesai? bukankah akan menimbulkan banyak legacy code? Nah, di sini lah clean code mengambil peran. Project open source maupun open contribute wajib menerapkan clean code termasuk coding style standar. Hal ini akan memudahkan handover task antar dev tanpa perlu transfer of knowledge lagi.
Fun Fact #4: Tech stack hopping bisa merugikan diri sendiri dan tim
Inilah fakta menarik yang paling mencengangkan! Tech stack hopping makna nya adalah berpindah-pindah tech stack sebelum benar-benar menguasainya. Alasannya sederhana saja: harus sesegera mungkin beradaptasi dengan tech stack baru supaya memiliki kesempatan untuk mendapat job.
Jika kita melihat ke linkedin atau github, mungkin sering ada yang mengisikan informasi tech stack yang sudah dikuasai. Ada yang mengaku bisa lebih dari 3 bahasa pemrograman, ada yang mengaku bisa lebih dari 3 framework, ada yang mengaku bisa lebih dari 3 deployment system, dst. Namun ketika interview banyak yang failed sebab fitur-fitur dari tech stack yang disyaratkan dalam suatu project ternyata alpa dikuasai pelamar. Parahnya, ada tim rekrutmen yang tetap menerima pelamar meski minim penguasaan nya terhadap tech stack yang disyaratkan.
Kenapa terjadi ada pelamar yang portfolio nya wow namun aslinya penguasaan nya minim? Ya itu tadi, tech stack hopping. Akibatnya mereka cenderung hanya melatih skillnya pada fitur-fitur standar. Katakan ada backend framework baru maka para tech stack hopper hanya melatih pada CRUD namun meninggalkan coding standard, fitur-fitur penting bahasa basis nya, middleware, dst. Dalih nya fitur tadi bisa dipelajari sambil jalan.
Kerugian tim yang diisi tech stack hopper jelas: project berjalan tersendat-sendat sebab ada fitur-fitur dasar yang dibutuhkan namun tidak dikuasai secara mendalam oleh dev nya, misalnya integrasi oAuth dengan backend framework atau integrasi payment gateway dengan frontend framework. Sedangkan kerugian di sisi tech stack hopper, jam produktif nya tersita untuk mendalami tech stack yang digunakan.
Atas dasar inilah penting bagi seorang dev untuk tidak buru-buru memelajari tech stack baru sebelum benar-benar menguasai tech stack lama. Meskipun ujung-ujung nya terlihat stuck pada 1 atau 2 tech stack namun dia bisa bekerja lebih optimal berkat penguasaan nya yang mendalam.
Kesimpulan
Hal yang bisa kita tarik dari beberapa fun fact di atas ada pada quote yang bermakna tidak ada teknologi bisa memenuhi segala kebutuhan client. Suka tidak suka akan ada saat nya tim dev memakai lebih dari 1 macam teknologi. Dan mau tidak mau harus melakukan collab dengan banyak dev yang skill nya beragam. Dev yang baik bukan yang mengantisipasi perkembangan teknologi namun yang siap bekerjasama untuk membuat aplikasi yang bekerja sebagaimana seharusnya.
Top comments (0)