Cartoon by Scott Simmerman

Menyambut Kelahiran Davin

Hari ke-empat di bulan suci Ramadhan 1441H atau Senin 27 April 2020 (Masehi) atas izinNya, telah dilahirkan putra pertama anak pertama kami, yang kami beri nama Davin dan disematkan nama marga Afifudin.

Semula proses persalinan dijadwalkan Selasa pagi 28 April, namun ketika kami tiba di RS pada malam hari sebelumnya untuk dilakukan pemeriksaan dan persiapan-persiapan, ternyata dari hasil pemeriksaan tersebut maka tim medis memutuskan agar proses persalinan dipercepat, yaitu malam itu juga. Puji Tuhan berjalan lancar dengan catatan kelahiran pukul 21.21.

Davin lahir di masa puasa Ramadhan dan ketika dunia sedang dilanda pandemi Covid-19. Prosedur-prosedur dari RS yang harus dilakukan antara lain rapid test untuk ibu Davin sebelum tindakan medis dilakukan, rapid test bagi Davin ketika lahir, suami tidak diperkenankan masuk ke ruang tindakan untuk mengurangi risiko Covid-19, dan tidak diperbolehkan tamu berkunjung selama dirawat di RS, kecuali neneknya namun dianjurkan juga tidak. Domisili orang tua saya & istri juga bukan di Bandung, dan karena pembatasan pergerakan masyarakat terkait Covid-19, maka hanya kami berdua yang saling menemani dibantu dengan semua staf medis RS.

Berselang 3 hari kemudian, tanggal 30 April, dokter penanggung jawab dengan memperhatikan perkembangan Davin dan ibunya, maka kami diizinkan untuk pulang ke rumah. Jalanan di kota Bandung dalam masa-masa tersebut relatif sepi dikarenakan anjuran dan peraturan agar orang-orang bekerja dari rumah (work from home) dan menghindari bepergian jika tidak penting.

Pertimbangan Membeli Komputer Mainframe

Semahal dan secanggih apapun komputer server yang dibeli, termasuk mainframe, manfaat yang diperoleh ditentukan oleh beberapa faktor, terutama:

• Ketersediaan software sesuai kebutuhan. Jika ternyata komputer tersebut tidak memiliki software yang dibutuhkan, maka tentu harga yang mahal menjadi sia-sia. Kemampuan processing yang diunggulkan di spesifikasi hardware menjadi tidak maksimal penggunaannya bahkan mungkin memberikan hasil yang tidak jauh berbeda dengan komputer server non-mainframe. Ketersediaan software ini pun harus sesuai dengan kebutuhan-kebutuhan yang spesifik dari organisasi/perusahaan, yang mana kebutuhan tersebut dijadikan alasan pengadaan server yang mahal. Dan bukan tidak mungkin jika kebutuhan tersebut tidak bisa dipenuhi oleh software yang telah tersedia di pasaran, sehingga harus dibangun khusus dan direkayasa (engineered) sedemikian rupa agar mendayagunakan sumber daya yang menjadi keunggulan server mahal tersebut.
• Data yang menjadi masukan bagi software. Masih terkait dengan faktor pertama di atas, bagaimana data yang menjadi input diperoleh dan diolah oleh software. Jika data input tidak berkualitas keabsahannya maka keluaran yang diberikan juga tidak bisa dijadikan pegangan bagi pihak yang berkepentingan. Masalah data ini turut dipengaruhi oleh rancangan software dan tentunya kembali ke apa kebutuhan dari sistem yang hendak dibangun.
• Pengoperasian software dan hardware (komputer server). Jika kemampuan pengoperasian baik oleh manusia ataupun secara otomatis oleh mekanisme apapun itu, tidak memadai atau tepat, maka outcome-nya juga tidak maksimal atau bahkan salah. Pengoperasian dalam hal ini juga  meliputi bagaimana data disediakan dan diinput (apakah secara manual atau dalam bentuk lain) serta bagaimana hasil output dimanfaatkan.

Jadi apakah sudah tepat merumuskan kebutuhan sehingga memerlukan tenaga komputasi yang disediakan oleh server mahal? Bagaimana kesanggupan untuk pengoperasiannya? Dan bagaimana perawatannya apakah pengadaan ini untuk kebutuhan jangka panjang atau hanya 1-3 tahun saja?

Framework Marriage

Our team have been building a software for more than a year, and sometimes it makes me think about our framework usage. Then I read this passage from Robert C. Martin book, Clean Architecture which I mostly agree:

Asymmetric Marriage
The relationship between you and the framework author is extraordinarily asymmetric. You must make a huge commitment to the framework, but the framework author makes no commitment to you whatsoever.

Think about this point carefully. When you use a framework, you read through the documentation that the author of that framework provides. In that documentation, the author, and other users of that framework, advise you on how to integrate your software with the framework. Typically, this means wrapping your architecture around that framework. The author recommends that you derive from the framework's base classes, and import the framework's facilities into your business objects. The author urges you to couple your application to the framework as tightly as possible.

For the framework author, coupling to his or her own framework is not a risk. The author wants to couple to that framework, because the author has absolute control over that framework.

What's more, the author wants you to couple to the framework, because once coupled in this way, it is very hard to break away. Nothing feels more validating to a framework author than a bunch of users willing to inextricably derive from the author's base classes.

In effect, the author is asking you to marry the framework - to make a huge, long-term commitment to that framework. And yet, under no circumstances will the author make a corresponding commitment to you. It's a one-directional marriage. You take on all the risk and burden; the framework author takes on nothing at all.

The Risks
What are the risks? Here are just a few for you to consider.

• The architecture of the framework is often not very clean. Frameworks tend to violate the Dependency Rule. They ask you to inherit their code into you business objects - your entities! They want their framework coupled into that innermost circle. Once in, that framework isn't coming back out. The wedding ring is on your finger; and it's going to stay there.
• The framework may help you with some early features of your application. However, as your product matures, it may outgrow the facilities of the framework. If you've put on that wedding ring, you'll find the framework fighting you more and more as time passes.
• The framework may evolve in a direction that you don't find helpful. You may be stuck upgrading to new versions that don't help you. You may even find old features, which you made use of, disappearing or changing in ways that are difficult for you to keep up with.
• A new and better framework may come along that you wish you could switch to.

The Solution

What is the solution?

Don't marry the framework!

Kembali Lembur Malam Hingga Dini Hari

Di usia yang semakin bertambah ini, dan meski telah memiliki beberapa rekan muda di perusahaan, tentu masih ada urusan yang memerlukan saya untuk menyelesaikannya secara langsung. Dalam 4 hari terakhir ini saya kembali melakukan aktivitas hingga lewat tengah malam.

Hari pertama, janjian dengan tim IT klien kami di Padalarang untuk melakukan maintenance server linux. Dikarenakan staf kami dan klien masih kurang pengalaman dengan linux, maka saya tangani langsung. Jadwal pengerjaan dimulai dari 22.30 hingga menjelang 02.30. Tentunya ada variabel-variabel X yang muncul secara tidak terduga dan terpaksa dicarikan solusinya dengan analisis dan sintesa pengetahuan.

Hari yang ke-dua, berangkat menuju kota Makassar. Dengan ditemani salah satu staf programmer kami, tepat pukul 02.02 meluncurlah kami ke Bandara Udara Kertajati dari kota Bandung. Sopir travel lumayan kebut dan ~2 jam (pukul 04.01) kami tiba di area keberangkatan.

Hari yang ke-tiga, setelah tiba di kota Makassar dan langsung berkegiatan di lokasi-lokasi klien, saya baru kembali ke rumah setelah pukul 22.30. Yang ini tentu tidak sampai lewat tengah malam.

Hari ke-empat, kembali melakukan maintenance server di lokasi klien yang lain lagi. Maintenance dilakukan menunggu ditutupnya aktivitas operasional. Dimulai sekitar pukul 23.00 hingga selesai pukul 2 dini hari.

Semoga semua aktivitas yang kami lakukan memberi manfaat bagi banyak orang dan dihitung sebagai amal ibadah.

Feasibility dan Visibility dari Proyek Pembangunan Perangkat Lunak

Dua kata yang pengucapannya mirip yaitu feasibility dan visibility. Namun yang pertama memiliki arti kelayakan dan yang terakhir visibilitas (jelas terlihat/terbaca).

Dalam konteks software project management, dulu saya pikir dua hal ini sama, bahkan mengira penulisan seperti "visibilitas proyek" adalah salah tulis yang harusnya "kelayakan proyek" alias project feasibility, tapi ternyata memang berbeda maknanya. Secara umum saya mengambil definisi berikut (setelah baca sana sini, terutama dari https://www.simplilearn.com/feasibility-study-article dan https://www.liquidplanner.com/blog/project-management-challenge-5-no-visibility-project-status/):

Feasibility (kelayakan) proyek adalah penilaian potensi keberhasilan dari pengerjaan proyek. Feasibility ini adalah aspek yang harus dilakukan di awal untuk menentukan layak tidaknya suatu proyek dilaksanakan. Jika dinilai tidak layak maka tidak dikerjakan atau dicarikan solusi lain. Berdasarkan situs simplilearn di atas, ada 5 jenis studi kelayakan yaitu:

1. Kelayakan Teknis
2. Kelayakan Ekonomi
3. Kelayakan Legalitas (aspek hukum)
4. Kelayakan Operasional
5. Kelayakan Penjadwalan

Lebih lanjut tentang kelima hal di atas, bisa dibaca di link simplilearn di atas.

Adapun Visibilitas proyek adalah kejelasan progress atau perkembangan kemajuan dari proyek. Termasuk juga dalam hal ini adalah penggunaan sumber daya (resource allocation) dan risiko-risiko yang potensial. 

Jika kita tidak mudah mencari tahu bagaimana perkembangan proyek sampai dengan saat ini? Siapa sedang mengerjakan apa? Apa hambatan/masalah yang ditemui dalam pengerjaan suatu modul yang sedang berlangsung? Butuh berapa lama waktu untuk menyelesaikan suatu modul atau fitur? Maka ini berarti visibilitas proyek kurang.

Untuk dapat menunjang visibilitas maka aktivitas-aktivitas utama dalam proyek harus bersifat trackable, komunikasi tim juga harus baik. Pemanfaatan tools dan dokumentasi juga sangat berperan untuk menunjang visibilitas. Tools seperti Trello, Atlassian Jira, atau Gitscrum bisa dipakai untuk melacak tugas-tugas yang akan/sedang/telah dikerjakan. Tiap tool biasa menawarkan fitur-fitur tambahan selain pelacakan, tapi jangan sampai terjadi juga, yaitu tata cara atau pendekatan yang kita pakai dalam monitoring & control proyek didikte oleh tools yang dipakai sedangkan kebutuhan yang sesungguhnya ternyata berbeda.

Lemah Empati

Sedang mengantri pesan makanan di Burger King salah satu cabang di Gowa. Nampak isi toko ramai dan antrian di kasir juga berjubel. Beberapa orang kesulitan mendapatkan tempat duduk karena penuh terisi. Yang sedang antri memesan juga was-was seandainya sudah siap santap tapi tidak kebagian tempat duduk. Begitulah risiko kalau tempat sedang ramai dan penuh terisi.

Ada situasi yg tidak wajar saya jumpai, yaitu orang-orang yg telah selesai makan masih duduk lama tanpa peduli bahwa banyak orang lain yg sedang mencari tempat. Mereka merasa bukan masalahnya, toh sudah membayar dan sepenuhnya hak mereka mau duduk berapa lama pun. Tipikal seperti ini berarti empatinya sangat kurang bahkan mungkin tidak ada. Bisa jadi karena tidak pernah dididik untuk memiliki empati ke sesama manusia maupun makhluk.