Hype Driven Development. Kebiasaan buruk dalam Software Engineering
Because premature optimization is the root of all evil
The Circle of Evil
Sebagai seorang mahasiswa, saya sering berdiskusi dengan teman-teman mengenai perkembangan teknologi saat ini. Kami berdiskusi di semua lini platform, dari Web, Mobile maupun Embedded device, dari sisi bahasa, mulai dari C++, PHP sampai Rust. Dari SOAP atau JSON maupun Protobuf, dari RabbitMQ sampai Kafka , MySQL hingga MongoDB, kami buat hirarki nya, dari yang terbawah hingga teratas. Tidak jarang kami menggunjing satu programming language sebagai dead language hanya karena performa nya selalu kalah dengan bahasa-bahasa baru yang sedang hype di Internet
Tak jarang juga, kami menyindir materi-materi “Out of date” yang diberikan Dosen hanya karena sudah jarang di temukan di media teknologi mainstream. Tidak hanya di Kampus, di tempat kerja pun sama, kami saling berbincang tentang teknologi-teknologi hot yang harus di naikkan ke production, dengan mengorbankan beberapa pekan untuk belajar hal baru dan melupakan best-practice yang telah ada bertahun-tahun lamanya dalam pembuatan software.
Premature Optimization, Overdue Shipping
Optimizing things is fun, but it’s not always the right task to choose. Performance is a feature, but so is shipping, and so is correctness.-
Sebenarnya, tujuan utama dalam coding itu apa? Bukankah untuk menyelesaikan masalah? Ya, tepatnya, untuk memenuhi kebutuhan bisnis. Lalu, apakah dengan menghemat space memory ~10 KB dari program yang sudah berjalan ini, merupakan salah satu penyelesaian masalah? Mungkin iya, jika kita bekerja di Google atau Amazon. Namun dengan skala aplikasi yang digunakan saat ini, apakah lebih baik jika 2 minggu waktu yang kita pakai untuk optimisasi itu dipakai untuk hal lain?
Doing test is boring, and so to change all the REST API to gRPC
Sebagai developer, saya akui, membuat test code memanglah membosankan, seperti mengerjakan ulang sebuah fitur yang sudah jadi, namun, hal ini tidak berlaku, ketika saya menulis ulang code base yang berjalan dengan teknologi baru yang di claim lebih cepat. Ini terjadi karena hormon endorphin yang muncul dari hasil kebanggan dalam melakukan false heroic action.
Saya merasa bangga, sebagai seorang developer, dengan umur yang lebih muda, dapat membangun program yang lebih performan dibanding senior-senior saya. Padahal, saya yakin, mereka dapat membangun program yang 100 kali lebih cepat, namun semuanya kembali pada satu masalah: Time is a constraint everyone cannot deny
Pesan saya kepada teman-teman, se painful apapun kalian menulis test, lakukanlah. Dibanding kalian menghabiskan waktu untuk menulis ulang code menggunakan library lain, karena mengikuti hype.
Documentation is not less important
Mungkin men-dokumentasi aplikasi, selalu dilakukan dengan cara yang sama, tidak ada hype yang muncul seperti bahasa program ataupun library baru di Android Jetpack. Lalu, apakah anda ingin mengemban konsekuensi menulis ulang dokumentasi ketika codebase diubah? Atau anda tidak menulis dokumentasi sama sekali?
Microservice? Are you strong enough to handle it?
“Kita akan membangun project ini dengan microservice” teriak seorang junior developer muda yang naif, pada suatu project payroll sederhana yang ditujukan ke perusahaan menengah dengan deadline 2 bulan.
Padahal, cukup dengan aplikasi monolith, kita bisa menghemat 2minggu mengatur Gateway API kita dan menggunakan waktu itu untuk melakukan QA Testing, supaya 1 minggu kemudian, kita tidak menghabiskan waktu men-debug bug pada salah satu service.
Lalu, kira-kira di service mana ya bug itu terjadi?
Eventually, what you consider obsolete in College, is the base foundation of what the Software architect built on
Ketika saya mendevelop aplikasi berbasis arsitektur event-stream, saya menyadari bahwa ternyata materi mengenai ESB (Enterprise Service Bus) merupakan suatu konsep awal yang dipakai sebelum adanya teknologi event-queue seperti Apache Kafka. Materi yang diajarkan pada mata kuliah Rekayasa Perangkat Lunak pada semester 2 itu awalnya banyak saya lihat “sebelah mata”, bukan hanya karena bersifat lebih teoritis, namun buku-buku yang direferensikan dosen saya, adalah cetakan-cetakan tahun 2000 awal. Padahal banyak dari apa yang diajarkan di mata kuliah itu, ternyata masih relevan hingga sekarang, hanya di-rebranding saja.
Memang saya akui, kebanyakan praktikum yang ada di perkuliahan sampai saat ini, saya rasakan obsolete, namun, yang kadaluarsa itu, bukan konsepnya, tapi teknisnya. Lalu, bukannya itu semua harusnya jadi perkara nomor sekian bagi developer? Syntax yang deprecated, API baru yang muncul, tambahan parameter, callback tambahan yang harus di handle, layer abstraksi baru, semuanya adalah masalah teknis saja, pada akhirnya, semua itu bertuju pada satu penyelesaian yang sama. Jadi, yang terpenting, adalah bagaimana kita, sebagai seorang programmer, dan juga engineer yang akan menentukan arah masa depan aplikasi yang kita bangun, dapat sustain lebih lama.
Conclusion
Back to basic, Coba sekali-kali lihat source code dari library yang kita pakai. Jangan terlalu terpukau dengan layer abstraksi dari library yang digunakan. Walaupun menawarkan speed yang lebih, apakah kita sudah tau drawbacknya? Kerja lah secara tim, pikirkanlah apakah rekan kerja lainnya sudah familiar dengan teknologi yang ingin kita pakai? Apakah mengorbankan waktu untuk me refactor code yang sudah berjalan itu worth it? Ingat bahwa apa tujuan utama kita membangun aplikasi. berbincanglah dengan orang bisnis, apa primary goal, main priority dan definition of done nya. Dan terakhir, strive for corectness, not performance.
***
Don’t underestimate the old tech, as they are what define the now-tech.
