Cara Pribadi Saya Mengembangkan Software dengan Cepat
(evanhahn.com)- Menyeimbangkan kesempurnaan dan kecepatan memang tidak mudah, tetapi yang penting adalah kualitas yang memadai sesuai situasi dan memenuhi tenggat waktu
- Efektif untuk lebih dulu membuat draf awal (rough draft), lalu setelah itu meningkatkan kualitas kode
- Dengan melonggarkan requirement atau mengurangi tuntutan yang berlebihan, kecepatan dan efisiensi bisa ditingkatkan
- Perlu membiasakan diri untuk menghindari distraksi dan sering melakukan commit dalam unit kecil, serta fokus pada hal yang inti
- Ada keterampilan konkret yang membantu pengembangan cepat, seperti membaca kode, pemodelan data, scripting, debugging, dan berorientasi pada pure function
“Seberapa bagus kode seharusnya?” – Standar kualitas dan pilihan yang realistis
- Pada awalnya saya ingin semua kode sempurna
- Saya memimpikan semua fungsi diuji dengan ketat, nama variabel elegan, abstraksi jelas, dan kode tanpa bug sama sekali
- Tetapi seiring waktu saya belajar kenyataan bahwa “tidak ada jawaban yang benar”
- Kualitas kode yang dibutuhkan berbeda tergantung situasi
- Game jam 24 jam: kode yang selesai tidak harus rapi atau bebas bug sepenuhnya
- Yang lebih penting adalah membuat hasil yang berjalan dalam waktu terbatas
- Software pacemaker: satu kesalahan saja bisa mengancam nyawa seseorang, sehingga
- tingkat keandalan dan keselamatan tertinggi adalah hal yang wajib
- Sebagian besar proyek berada di antara dua ekstrem ini
- Ada perusahaan yang menuntut deadline cepat sehingga sedikit bug masih bisa diterima
- Ada proyek yang menuntut kualitas tinggi tetapi jadwalnya longgar
- Dalam pekerjaan nyata, kemampuan memahami keseimbangan ini sangat penting
- Hal pertama yang perlu dipahami adalah apa standar tim untuk ‘cukup baik (good enough)’
- Periksa bersama standar praktis seperti sejauh mana bug dapat diterima dan bagian mana yang tidak harus sempurna
- Standar pribadi saya adalah
- “mencapai kualitas 8 dari 10, tepat waktu”
- Kode menjalankan tujuannya dengan baik, tidak ada masalah kritis, tetapi mungkin masih ada isu kecil yang tersisa
- Yang paling penting adalah mengirimkannya sebelum tenggat
- Namun, standar ini pun saya sesuaikan secara fleksibel menurut konteks proyek
- Kadang mengejar kesempurnaan meski jadwal mundur masih bisa diterima,
- dan kadang penyelesaian yang belum sempurna tetapi cepat justru lebih bernilai
- “mencapai kualitas 8 dari 10, tepat waktu”
Rough drafts – penggunaan praktis dan kelebihan rough draft serta prototyping
- Dalam pengembangan software, seperti halnya menulis, membuat draf awal (rough draft, spike, walking skeleton) sangat berguna
- Saya mengimplementasikan rough draft secepat mungkin, lalu menyempurnakannya menjadi solusi final
- Kode rough draft saya penuh bug: test gagal, komentar TODO bertebaran, exception belum ditangani, print/log dipakai berlebihan,
tanpa mempertimbangkan performa, pesan commit WIP, penambahan package yang tidak perlu, kode berulang, hardcoding, peringatan linter, dan segala bentuk kekacauan lainnya - Proses ini mungkin terlihat tidak efisien, tetapi tujuannya adalah mencapai “setidaknya kondisi di mana inti masalah bisa dipahami”
- Tentu saja, kode dalam kondisi draf seperti ini tidak dikirim sebagai rilis final, dan sebelum benar-benar dirilis harus dirapikan
(kadang ada tekanan di tim untuk mengirim kode draft apa adanya, tetapi saya berusaha menolaknya sebisa mungkin) -
Kelebihan utama pendekatan rough draft
- Mengungkap “masalah yang belum diketahui (unknown unknowns)” lebih cepat
- Jauh lebih menguntungkan menemukan hambatan yang belum terlihat pada tahap prototipe awal daripada setelah kode selesai lalu dibuang
- Banyak masalah yang hilang dengan sendirinya selama pembuatan prototipe
- Fungsi yang lambat atau struktur yang keliru sering kali pada akhirnya malah tidak diperlukan sama sekali, sehingga menghindarkan pemborosan waktu
- Tidak perlu terlalu dini menghabiskan tenaga untuk optimasi atau test
- Meningkatkan fokus
- Mencegah distraksi seperti refactoring yang tidak perlu, terlalu lama memikirkan naming, atau memperbaiki codebase lain,
sehingga bisa fokus sepenuhnya pada masalah yang sedang harus diselesaikan
- Mencegah distraksi seperti refactoring yang tidak perlu, terlalu lama memikirkan naming, atau memperbaiki codebase lain,
- Mencegah abstraksi prematur yang tidak perlu
- Dalam proses membuat solusi yang berjalan dengan cepat, kita jadi lebih jarang mencoba abstraksi yang belum diperlukan untuk masa depan
- Fokus hanya pada masalah saat ini membantu menghindari desain yang tidak perlu rumit
- Komunikasi progres yang lebih jelas
- Dengan rough draft, jadi lebih mungkin memprediksi dengan akurat berapa banyak pekerjaan yang tersisa
- Dengan lebih dulu menunjukkan sesuatu yang bekerja, feedback stakeholder dan perubahan arah bisa terjadi lebih cepat
- Mengungkap “masalah yang belum diketahui (unknown unknowns)” lebih cepat
-
Cara menjalankan rough draft dalam praktik
- Keputusan yang sulit dibalik (binding decision) harus diuji pada tahap draft
- Contoh: bahasa, framework, skema DB, dan arah besar lainnya perlu divalidasi lebih awal
- Semua solusi sementara/hack harus dicatat dengan komentar TODO atau sejenisnya
- Pada tahap polish (perapian), semuanya ditinjau satu per satu dengan
git grep TODOdan sejenisnya
- Pada tahap polish (perapian), semuanya ditinjau satu per satu dengan
- Mengembangkan dengan urutan Top-Down (atas-ke-bawah)
- Mulai dari cara penggunaan seperti UI, API, lalu membuat scaffold; logika internal boleh di-hardcode atau diimplementasikan sementara
- Dalam praktiknya, logika level bawah sering berubah saat UI/pengalaman pengguna mulai jelas, jadi membangun dari layer atas lebih menguntungkan
- Menyempurnakan level bawah lebih dulu lalu menyesuaikannya dengan level atas itu tidak efisien
- Pisahkan perubahan kecil menjadi patch tersendiri
- Jika saat rough draft Anda menemukan perlunya perbaikan codebase atau update dependency,
pisahkan bagian itu ke PR/commit terpisah agar bisa segera diterapkan - Ini mengurangi kompleksitas perubahan keseluruhan dan mempercepat review/integrasi
> Referensi: “Throw away your first draft of the code”, “The best simple system for now”, “YAGNI(You Aren’t Gonna Need It)”
- Jika saat rough draft Anda menemukan perlunya perbaikan codebase atau update dependency,
- Keputusan yang sulit dibalik (binding decision) harus diuji pada tahap draft
Mencoba mengubah requirement
- Menekankan prinsip bahwa melakukan lebih sedikit itu lebih cepat dan lebih mudah
- Dalam pekerjaan nyata, saya selalu memikirkan apakah requirement dari tugas yang diberikan bisa dilonggarkan
- Contoh pertanyaan:
- Bisakah beberapa layar digabung menjadi satu?
- Apakah edge case yang rumit benar-benar harus ditangani?
- Jika harus mendukung 1000 input, apakah 10 saja sebenarnya sudah cukup?
- Bisakah diganti dengan prototipe alih-alih versi lengkap?
- Apakah fitur ini sendiri bisa dihapus?
- Contoh pertanyaan:
- Pendekatan seperti ini meningkatkan kecepatan dan efisiensi pengembangan
- Saya juga mencoba mendorong budaya organisasi agar bergerak sedikit demi sedikit ke tempo yang lebih lambat dan lebih masuk akal
- Tuntutan perubahan yang mendadak dan besar biasanya tidak efektif
- Suasana bisa diubah sedikit demi sedikit melalui usulan bertahap dan perubahan cara berdiskusi
Menghindari distraksi dalam kode
- Bukan hanya lingkungan luar (notifikasi, rapat), tetapi juga terseret ke pekerjaan lain yang tidak relevan saat sedang coding adalah gangguan besar
- Saya pun sering kali saat memperbaiki bug malah membongkar bagian yang sama sekali tidak terkait, dan pada akhirnya tugas utama tertunda
- Dua praktik konkret:
- Setel timer: beri batas waktu pada setiap tugas, lalu saat alarm berbunyi, periksa progres saat ini
- Ini membantu menyadarkan ketika pekerjaan memakan waktu lebih lama dari perkiraan
- Jika bersamaan dengan alarm melakukan git commit, ada rasa pencapaian kecil juga
- (Metode ini juga efektif untuk melatih estimasi waktu)
- Pair programming: bekerja bersama membantu mengurangi kecenderungan menyimpang ke arah yang tidak perlu dan menjaga fokus
- Setel timer: beri batas waktu pada setiap tugas, lalu saat alarm berbunyi, periksa progres saat ini
- Bagi sebagian developer, menghindari distraksi seperti ini terjadi secara alami, tetapi bagi saya dibutuhkan fokus yang sadar dan pembiasaan
Perubahan dalam unit kecil, dipecah sekecil mungkin
- Dulu ada atasan yang mendorong patch besar dan perubahan berskala luas,
tetapi saya mengalami sendiri bahwa itu sangat tidak efisien - Menurut saya, diff yang kecil dan terfokus hampir selalu lebih baik
- Beban menulis kode lebih ringan
- Code review jadi lebih mudah dan cepat, mengurangi kelelahan rekan kerja, dan kesalahan saya juga lebih mudah ditemukan
- Jika ada masalah, rollback lebih mudah dan aman
- Karena cakupan perubahan sekaligus kecil, risiko munculnya bug baru juga berkurang
- Fitur besar/penambahan fitur pun pada akhirnya selesai lewat akumulasi perubahan kecil
- Contoh: jika perlu menambahkan layar baru, pisahkan perbaikan bug/upgrade dependency/penambahan fitur ke patch yang berbeda
- Ditekankan bahwa perubahan dalam unit kecil membantu pengembangan software yang lebih cepat dan berkualitas lebih tinggi
Keterampilan konkret yang benar-benar membantu pengembangan cepat
Hal-hal yang dibahas di atas agak abstrak, tetapi ada juga keterampilan praktis yang benar-benar efektif untuk pengembangan cepat
-
Membaca kode (Reading code): ini adalah kemampuan developer paling penting yang saya peroleh sejauh ini
- Jika bisa memahami kode yang sudah ada dengan baik, debugging jadi jauh lebih mudah
- Bug pada library open source/third-party atau dokumentasi yang kurang juga jadi tidak terlalu menakutkan
- Belajar dengan membaca kode orang lain juga sangat besar manfaatnya, dan secara langsung membantu meningkatkan kemampuan pemecahan masalah secara umum
-
Pemodelan data (Data modeling): meski memakan waktu, penting untuk merancang model data dengan benar
- Skema database yang dirancang keliru akan menimbulkan berbagai masalah dan biaya perubahan yang rumit di kemudian hari
- Merancang agar state yang tidak valid sama sekali tidak bisa direpresentasikan akan mengurangi bug dari akarnya
- Jika data disimpan atau dipertukarkan dengan pihak luar, kehati-hatian menjadi jauh lebih penting
-
Scripting: kemampuan menulis script pendek dengan cepat menggunakan Bash, Python, dan lainnya sangat memaksimalkan efisiensi pengembangan
- Digunakan beberapa kali setiap minggu untuk otomatisasi seperti merapikan Markdown, membersihkan data, atau mencari file duplikat
- Untuk Bash, alat seperti Shellcheck membantu mencegah kesalahan sintaks lebih awal
- Untuk pekerjaan yang tidak perlu terlalu robust, bantuan LLM bisa dipakai agar selesai lebih cepat
-
Memakai debugger (Debuggers): penggunaan debugger penting untuk diagnosis masalah yang cepat dan memahami alur kode dengan cara yang tidak mungkin dicapai hanya dengan print/log
- Menemukan akar penyebab bug yang kompleks jadi jauh lebih cepat
-
Waktu yang tepat untuk beristirahat: kebiasaan berani beristirahat saat buntu
- Sering terjadi bahwa masalah yang tak terpecahkan setelah lama berjuang justru selesai segera setelah istirahat 5 menit
- Ini juga penting untuk efisiensi fokus
-
Berorientasi pada pure function dan immutable data: functional programming: jika lebih menyukai pure function dan immutable data,
- bug berkurang, beban melacak state menurun, dan kejelasan/prediktabilitas kode meningkat
- Dalam banyak kasus ini lebih sederhana dan efektif daripada merancang hierarki class yang rumit
- Memang tidak selalu mungkin, tetapi secara default pendekatan ini saya pertimbangkan lebih dulu
-
Memanfaatkan LLM (large language model): LLM (misalnya ChatGPT, dll.) punya kelemahan juga, tetapi dapat sangat meningkatkan kecepatan untuk pekerjaan pengembangan yang repetitif atau bisa diotomatisasi
- Setelah cukup memahami cara menggabungkan LLM ke dalam alur kode sendiri beserta batasannya, saya aktif memanfaatkannya
- Saya juga merujuk pada berbagai pengalaman, tips, dan contoh dari komunitas
Semua keterampilan ini telah saya latih berulang kali selama waktu yang panjang, dan benar-benar menjadi aset besar untuk pengembangan cepat
Ringkasan
- Pelajaran inti yang saya peroleh saat mengembangkan software dengan cepat adalah sebagai berikut
- Pahami dengan jelas standar kualitas kode yang dibutuhkan untuk tiap tugas
- Tulis rough draft (draf awal) dengan cepat untuk membentuk gambaran keseluruhan
- Selalu cari ruang untuk melonggarkan requirement
- Jaga fokus tanpa mudah terdistraksi
- Commit perubahan kecil dan sering, serta hindari patch besar
- Terus latih keterampilan praktis yang konkret (membaca kode, pemodelan data, debugging, scripting, dll.)
- Semua ini tampak sangat jelas, tetapi butuh waktu lama bagi saya untuk benar-benar memperoleh pelajaran tersebut
2 komentar
Banyak hal yang terasa relevan di sini.
Komentar-komentarnya juga bagus; ketika seseorang merangkum dan menyampaikannya seperti ini, lalu menyediakan wadah untuk itu, rasanya pembahasan tersebut menjadi lebih lengkap melalui sanggahan, dukungan, dan tambahan.
Tambahan: belakangan ini saya sering melihat ungkapan "teknologi yang membosankan", dan dalam bahasa Inggris ternyata boring technology.
Opini Hacker News
Dalam beberapa tahun terakhir, saya merasa sudah menemukan cara membangun sistem yang cepat dan cukup kokoh
Saya belajar bahwa penting untuk benar-benar menguasai satu alat secara mendalam. Dibanding alat yang secara permukaan terlihat lebih cocok, alat yang saya kuasai jauh lebih efisien. Dalam praktiknya, untuk sebagian besar proyek, Django adalah pilihan yang pas
Kadang saya memulai proyek sambil khawatir Django mungkin terlalu berat, tetapi hasilnya proyek tumbuh jauh melampaui niat awal. Misalnya saya membuat aplikasi halaman status, lalu segera sadar bahwa upaya menghindari batasan Django justru tidak efisien
Untuk sebagian besar aplikasi yang cocok dengan model Django, model data adalah inti. Meski hanya prototipe, jika refaktor model data ditunda, biaya dan kesulitannya nanti akan meningkat secara eksponensial
Sebagian besar aplikasi tidak membutuhkan single-page app atau framework frontend yang berat. Sebagian kecil mungkin iya, tetapi untuk 80% halaman, view Django tradisional sudah cukup. Sisanya bisa mempertimbangkan AlpineJS atau HTMX
Dalam kebanyakan kasus, membangun sendiri lebih mudah. Dengan Django, fitur seperti CRM, halaman status, sistem dukungan, proses penjualan, dan lainnya bisa dibuat dengan cepat. Jauh lebih cepat daripada integrasi dengan CRM komersial.
Pilih teknologi yang biasa sampai membosankan. Kombinasi Python/Django/Postgres sudah cukup untuk sebagian besar kebutuhan. Lupakan Kubernetes, Redis, RabbitMQ, Celery, dan sebagainya. Alpine/HTMX adalah pengecualian, karena itu memungkinkan menghindari sebagian besar stack JS
Bagi saya, Redis dan Kubernetes justru adalah ‘teknologi membosankan’ tahun 2025. Keduanya sangat stabil, kegunaannya jelas, dan kekurangannya pun sudah dipahami dengan baik, jadi sangat dapat dipercaya. Saya pribadi penggemar keduanya. Keduanya melakukan persis apa yang saya inginkan, jadi saya sangat mempercayainya
Saya juga benar-benar suka Django. Memulai proyek dan men-deploy-nya bisa dilakukan dengan sangat cepat
Jika benar-benar memilih ‘teknologi membosankan’, bahkan Postgres pun layak dipikirkan dua kali
Saya cukup sering memakai Celery di proyek Django. Saya tidak suka kompleksitasnya, tetapi di lingkungan PaaS justru itu pilihan yang paling tidak menyakitkan
Klaim bahwa “sebagian besar aplikasi tidak membutuhkan SPA atau framework frontend yang berat” tampak bertentangan dengan saran “kuasai satu alat secara mendalam”
Saat kita meninggalkan kode sebagai draf kasar, sering kali manajer justru merilis kode itu apa adanya sebagai ‘versi final’
Karena itu saya menulis kode yang kokoh sejak awal. Bahkan test harness pun saya buat hampir setangguh tingkat produksi
Intinya adalah membuat modul yang benar-benar berkualitas tinggi. Bagian yang kemungkinan berubahnya sangat kecil, atau jika berubah akan menimbulkan masalah besar, saya isolasi sebagai modul independen lalu impor sebagai dependensi
Berkat modul-modul seperti ini, saya bisa mengembangkan aplikasi baru dengan sangat cepat sambil tetap menjaga kualitas tetap tinggi
Contoh yang pernah saya gunakan antara lain RVS_Checkbox, ambiamara, RVS_Generic_Swift_Toolbox dan sebagainya
Saya ada pertanyaan: apakah pola kode seperti
* ##################################################################sebagai penanda komentar di Swift itu standar?Pendekatan sangat berubah tergantung skala proyek
Untuk proyek pribadi atau tim kecil, mengembangkan secara ‘cepat dan kasar’ adalah yang paling optimal. Itulah kekuatan pengembangan skala kecil
Dalam skala kecil, bug pun bisa cepat diperbaiki, dan semua anggota tim hampir memahami seluruh kode secara sempurna
Saat skala membesar, biaya kesalahan arsitektur maupun perbaikan bug melonjak drastis. Arsitektur tak terhindarkan menjadi rumit, dan refaktor besar praktis mustahil. Dalam lingkungan seperti ini, ketepatan di setiap langkah harus menjadi prioritas utama
Konteks itu sangat penting. ‘Skala besar’ bisa berarti hal yang berbeda-beda, tetapi dari pengalaman saya, menyepakati API antar aplikasi lebih awal agar frontend/backend sama-sama cepat siap bekerja selalu merupakan keputusan yang tepat
Dalam situasi seperti ini, sistem harus diperkecil. Semua orang ingin sistem raksasa, padahal sebenarnya tidak membutuhkannya
Ada yang bilang “di game jam 24 jam tidak perlu memikirkan kualitas kode”, tetapi dari sebagian besar pengalaman saya di hackathon/code review, tim dengan hasil terbaik justru juga menjaga kualitas kode dan lingkungan pengujian yang sangat dasar sekalipun
Dua klaim di atas (kalau ingin cepat harus mengorbankan kualitas kode vs tim berprestasi justru kualitasnya tinggi) sebenarnya tidak bertentangan. Tim yang berkualitas tidak berarti selalu terobsesi pada kerapian kode saja
Dalam contoh game jam, jika terlalu terobsesi pada kebersihan kode, hasil akhir justru bisa jadi kurang bagus. Sistem seperti UE blueprint menunjukkan kenapa hasil akhir kadang perlu diprioritaskan di atas ‘kerapian’
Ada orang yang menilai ‘kebersihan’ kode secara menyeluruh, dan ada yang menilai biaya/manfaat rinci dari perbaikan kode yang tidak perlu
Berbeda dengan pernyataan bahwa “dengan prototyping, ‘unknown unknowns’ yang tak terduga akan muncul”, ketika saya pertama kali menyentuh sesuatu, saya justru selalu hanya melihat kelebihannya dan tidak begitu melihat kekurangannya
Dalam kenyataannya, masalah yang sebenarnya baru terlihat saat tahap penyelesaian fitur sesungguhnya: menangani edge case, pesan error yang ramah pengguna, menghilangkan efek samping, dan sebagainya
Mungkin unknown unknowns yang saya alami berasal dari alat/framework/library itu sendiri, sedangkan penulis berbicara tentang unknown unknowns dalam domain masalahnya
Benar juga bahwa rough draft tidak boleh terlalu kasar. Kalau kita asal lewat pada bagian yang seharusnya tidak boleh disepelekan, masalah nyata akan meledak di sana.
Saat membuat alat untuk dipakai sendiri, membuatnya secara seadanya sering kali tetap cukup baik untuk digunakan, dan alat yang dibuat secepat itu pun tidak terlalu menimbulkan masalah meski penuh celah
Di industri teknologi masa kini yang penuh restrukturisasi, itulah ancaman terbesar terhadap kualitas perangkat lunak dan produktivitas engineer
Kecemasan akan PHK dan tekanan untuk cepat menunjukkan hasil membunuh kreativitas dan semangat bereksperimen, serta memicu burnout
Semua orang terseret mentalitas kawanan pada isu tren seperti AI, dan lingkungan menjadi seperti tempat yang bahkan tak memungkinkan kritik
Ini masalah yang lebih mendesak daripada auto-coding berbasis LLM
Ancaman terbesar bagi kualitas perangkat lunak sebenarnya selalu adalah bahwa konsumen tidak mau membayar untuk kualitas
Vendor lock-in di level pemrograman sebenarnya jauh lebih merusak daripada lock-in SaaS
Dalam siklus cepat seperti game jam 24 jam, saya justru merasa kode yang buruk itu fatal
Semakin rapi kodenya, semakin sedikit kesalahan, semakin kecil beban pada working memory, dan semakin mudah melakukan perubahan yang diinginkan, menambah fitur, atau memperbaiki masalah di menit-menit akhir
Hal yang paling sering merusak proyek 24 jam bukanlah menulis kode terlalu lambat, melainkan menjebak diri sendiri di sudut atau terseret masalah tak terduga hingga keluar jalur
Tentu ini bukan berarti semua bug harus diperbaiki. Tetapi jika kualitas dasar rendah, keseluruhan pengalaman proyek akan terasa berat
Prinsip ini juga berlaku pada proyek dengan waktu lebih panjang. Punya lebih banyak waktu bukan berarti lebih baik menulis secara asal
Jika menulis kode yang baik sudah menjadi kebiasaan, kualitas bisa dijaga tanpa biaya tambahan. Dan bahkan kalau memang butuh waktu lebih pun, itu tetap hal yang bernilai
Saya setuju. Saya sudah beberapa kali ikut game jam, dan ‘kode berantakan’ hanya saya toleransi untuk 1-2 jam terakhir sebelum tenggat, di file yang tidak akan disentuh orang lain
Untuk menulis kode dengan cepat dan baik, pada akhirnya jawabannya adalah banyak berlatih
Saat terburu-buru, saya tidak memikirkan hal seperti asset loader yang fancy dan langsung memakai file statis saja
Saya pikir anggapan bahwa ‘menulis kode yang baik itu lebih lama’ adalah kesalahpahaman. Untuk memenuhi tingkat kebutuhan tertentu ke atas, kode yang baik tidak menjadi penghambat kecepatan
Standar tentang “seberapa jauh sesuatu dianggap ‘good enough’” berbeda-beda di tiap tim, dan itu adalah sumber konflik terbesar dalam karier saya
Orang dari big tech tidak puas dengan kurangnya pengujian, sementara orang dari startup mengeluh karena lajunya terlalu lambat
Akan berguna jika standar ‘good enough’ didokumentasikan dengan jelas dan dibagikan dalam tim
Itulah tepatnya team charter, yaitu dokumen tentang ‘cara kita bekerja’
Salah satu faktor penting yang tidak disebutkan dalam tulisan adalah penurunan kecepatan pengembangan seiring waktu
Ketika proyek dan ukuran tim membesar, kecepatan pengembangan secara alami melambat
Artinya, meski sedikit merugikan kecepatan jangka pendek, perlu menyiapkan sejak awal hal-hal seperti pengujian, dokumentasi, log keputusan, Agile meeting, dan sebagainya agar kecepatan pengembangan dalam jangka panjang tidak turun terlalu tajam
Jika sejak awal tidak menyiapkan hal-hal seperti observability atau struktur kode yang mudah diuji, dampak buruknya nanti bisa sangat besar
Sebagai solo developer, saya juga merasakan pentingnya tiga hal: log keputusan, pengujian, dan dokumentasi
Ini juga pola yang familier bagi saya. Untuk rough draft, atau validasi ide, saya mulai dari kode kecil yang membungkus bahasa skrip lain atau eksekusi manual